Claude Code vs Lovable

Add JWT authentication to the existing API in this repo. Read the current route structure first and tell me which routes you will protect before touching code. Implement: a login endpoint that verifies credentials against {{database}} and returns a short-lived access token plus a rotating refresh token stored server-side, middleware that validates signature, expiry, and audience on protected routes, and a logout that revokes the refresh token. Sign with an algorithm read from config, key from an environment variable; refuse to start if the variable is missing. Never log tokens. Write tests for: expired token rejected, tampered signature rejected, refresh rotation invalidates the old refresh token, and logout blocks reuse. Run the suite, then hit a protected route with curl three ways, no token, bad token, fresh token, and paste all three responses.

Add JWT-based authentication to this app using Supabase Auth, covering the client, the database, and the edge functions.

Flows: email and password signup with a confirmation step, sign in, a magic link option, password reset, and sign out. On signup, insert a row into a profiles table keyed to the new user id.

Route protection: redirect signed-out visitors from any authenticated route to /login with a return-to parameter, and send signed-in users away from /login. Keep the session in the Supabase client so a refresh does not log anyone out, and refresh tokens silently instead of bouncing to login when the access token expires.

Database: enable row level security on every user-owned table and write policies against auth.uid(), leaving no table with policies disabled.

Edge functions: each function reads the Authorization header, verifies the JWT through the Supabase client, and returns 401 with a JSON error body when it is missing or invalid. No function may fall back to the service role for user-scoped reads.

UI states: a loading gate while the session restores so protected pages never flash before redirect, inline errors for wrong credentials, and a resend link on the confirmation notice.

Acceptance: an expired session on a protected page recovers without a visible logout, calling an edge function with no header returns 401 not 500, password reset works end to end from the email link, and querying another user's rows from the browser console returns nothing.

Build a dashboard page in this codebase's existing frontend stack that surfaces {{resource}} metrics. Layout: a stat row with four summary cards (total, active, created this week, error count), a time-series chart of {{resource}} activity over the last 30 days, and a sortable table of the 20 most recent records with status badges. Fetch data through a typed client module rather than inline fetch calls, and handle three states per widget: loading skeleton, empty dataset with a short explanation, and fetch failure with a retry button. Keep the chart dependency-light; use whatever charting library is already installed before adding one. Make the grid collapse to a single column below tablet width. Add a component test for the table's sort behavior and the empty state. Run the dev build and the tests, then summarize the components you added and where they mount.

Build an analytics dashboard for an app that tracks {{resource}}.

Layout: fixed left sidebar (Overview, {{resource}}, Reports, Settings), a top bar with a date range picker (presets for last 7 days, last 30 days, and custom) and a user menu. Main area on a 12-column grid.

Overview page:
- Four stat cards: total {{resource}}, count added this period, percent change versus the prior period with a signed value, and a fourth card labeled Placeholder that I will define later.
- A line chart of daily counts across the selected range and a bar chart of the top five categories, both using Recharts inside responsive containers with explicit heights.
- A table of the 20 most recent records: sortable columns, a status badge, a row action menu, and pagination beyond 20 rows.

Data: create a Supabase table and seed roughly 90 days of plausible demo rows so every card and chart renders from real queries, not hardcoded arrays. Changing the date range must refetch and update every widget on the page.

States: skeleton loaders while queries run, an empty state with one line of explanation when the range has no data, and an inline retry button on query failure.

Styling: neutral grays with a single accent color, generous whitespace, no gradients. Works at 1280px wide; on mobile the grid collapses to one column and the sidebar becomes a drawer.

Skip auth for now. When finished, list which component reads from which table and column so I can point them at production data later.