Improve Seed Data So Preview Deployments Show Realistic Data

[cielbellerose]

Vercel/Neon preview deployments are hard to test against, because their data doesn't cover the states the app actually branches on. This ticket improves the seed data so previews show realistic, production-like data. The seeding setup stays the same.

Needs someone with Neon database access (step 3 below).

How previews get their data today

• npm run prisma:seed (and prisma migrate reset) runs prisma/seed.ts + prisma/seed/*.ts. It only runs by hand, against whatever .env points at.
• Previews are never seeded. vercel.json only runs prisma:migrate:deploy on VERCEL_ENV=preview, and no workflow seeds. The Neon Previews Integration creates each preview DB as a copy of a parent Neon branch (believed to be dev; confirm in the Neon console). So previews see whatever data that parent branch holds.
• The seed has a skip guard: if seed@aplio.dev exists, the whole seed is a no-op (prisma/seed.ts:25-35).
• Dates are offsets from the moment the seed runs, so states drift afterwards (a position closing "today" becomes closed the next day). Keep this behaviour; it's out of scope.

Plan of work

1. Extend the seed modules in prisma/seed/ with the scenarios below. Keep the existing structure, skip guard and date helpers.
2. Verify locally with npm run db:reset. Every scenario should be reachable through the bypass logins (/login/bypass).
3. Apply to the preview parent branch (needs DB access):
   • confirm which Neon branch previews copy from;
   • load the improved seed into it (a fresh branch or a reset, because of the skip guard);
   • check that a newly created preview shows the data.
     Don't touch the production branch. Mind the Neon 10-branch cap (CLAUDE.md → "Preview databases").
4. Document in the README which branch previews copy from and how to refresh its data.

Scenarios to add

From operator notes

• A draft application on a position whose deadline has passed (closed_by_date). This exercises the disabled Continue + tooltip from Hide The Continue Action On Past-Deadline Drafts #748.
• A withdrawn application on an open position (Edit & resubmit enabled).
• A withdrawn application on a position whose deadline has passed (Edit & resubmit disabled).
• The position manager (bypass) manages a mix of open, closed and draft positions.
• A global file_upload question matching a resume upload, answered on some applications.
• The position manager has their own draft application on a position that isn't open yet (upcoming).
• One of the position manager's open positions has at least one application in every status: draft, applied, reached_out, interview_scheduled, reviewing, accepted, rejected, withdrawn.

Currently-empty data

• Status history (ApplicationStatusEvent): realistic transition trails for non-draft applications, following docs/PERMISSIONS.md transitions. This populates history panels and the activity panel (Move Recent Activity Into A Global Activity Panel #617). The seed creates none today, so every history panel shows "No status changes recorded yet."
• Email log (EmailLog) across statuses: delivered, bounced (with a bounce type), complained, failed, suppressed, scheduled (inside the undo window) and cancelled, covering the templates in EmailTemplateKey. Some should be within 7 days so the admin failure strip shows. This populates the admin email log page (Add An Admin Email Log Page #553), which is empty today.

Awkward users and content

• A user with a blank or null name, to hit the name gate.
• A user with zero profile answers.
• A renamed applicant: applicantName on a submitted application differs from their current name.
• A manager with nothing to review (their positions have no applications).
• Long names, long answers and long position titles, to check wrapping and truncation (e.g. activity lines, mobile cards).
• A position with several managers, and one with an empty description.
• An open position with no close date.

Last sign-in (needs #645 / PR #777 merged)

• Set User.lastLoginAt across a realistic spread, so the Users page "Last sign-in" column and its sort show real data:
  • signed in minutes or hours ago;
  • a few days ago;
  • weeks ago;
  • months ago, to look dormant;
  • never (null), so the "—" and "No sign-in recorded" states and the nulls-last sort show up.
  • Include at least one admin and one manager in the "never" or "months ago" groups, and give the generated bulk applicants a mix too.
• Use offsets from the time the seed runs (the existing orgDayOffset / utcDayOffset helpers), like every other seeded date.
• If this ticket lands before Add A Last Sign-In Column To The Users Page #645, skip this section and leave a note. The column won't exist yet.

Volume

• One or two positions with 60+ generated applicants in a realistic status mix. That's past the 50-row pagination, and gives stats, status circles (Replace The Position Card Stat Tiles With Four Status Circles #682), data insights (Add An Admin Data Insights Page #744) and the manager digest (Manager Daily Digest #549) real numbers. Generated rows should use a deterministic helper, not random data that changes each run.

Out of scope

• Changing how or when seeding runs (no automatic seeding of previews, no CI changes).
• Fixing date drift or making the seed rerunnable.
• Real uploaded files. File-upload answers can point at placeholder blobs; Resume not showing up/showing as file name #762 is a separate bug.

Acceptance criteria

• npm run db:reset locally produces every scenario above, with no errors and no change to the existing seed's behaviour.
• A new preview deployment, created after step 3, shows the scenarios.
• The README says which Neon branch previews copy from and how to refresh it.
• npm run test still passes. The seed is not used by tests, but check that no shared fixture assumptions break.