Questions, answered

Each intake immediately enqueues generation (`resume_queue.job_type = generate_all`). Once artifacts finish uploading, a status token and delivery email are issued and a `send_email` job is queued. There is no hard SLA coded; delivery depends on queue throughput, but the pipeline runs as soon as jobs are picked up.

The intake requires an email, a valid tier code, and at least one job target. Submissions without these or with targets above the tier cap are rejected before any payment is recorded.

Yes. The intake file picker accepts application/pdf, .doc, .docx and stores the upload metadata inside intake_json. Uploading is optional—the request still processes with text entries alone.

Three tiers are available and shared across the site and intake validation:

- Starter (basic): $5.00 with up to 2 targets.

- Premium (enhanced): $10.00 with up to 3 targets.

- Executive (executive): $20.00 with up to 5 targets.

Yes. Generation writes plain-text resumes plus docx/pdf variants per target. Scorecards run pass 1/2 (and a third if the quality gate is still below threshold), and artifacts include cover letters (up to tier-specific limits) and interview prep for executive tiers.

Deletion requests set `delete_at` to ~3 days later (20:00 ET assumed as 01:00 UTC). A deletion notice is queued 12 hours before purge, and purge deletes storage artifacts, scrubs applicant PII and intake_json, marks status purged/hard_deleted_at, emits events, and queues a confirmation email. Contact attachments purge after 6 months and contact tickets anonymize + archive after 12 months.

Tokens are hashed and resolved against `access_campaigns`, with per-token limits for `expires_at`, `max_uses`, and optional `max_uses_per_email` plus revocation checks. Partner-bound tokens must match the partner slug on the request. Routes /promo/[token], /p/[partner_slug]/trial/[token], and /e/[event_slug]/[token] all flow through the same resolver.

Automatic refunds occur when a request is marked terminal and the system queues a `refund_payment` job (policy B) for paid Stripe requests. Eligibility still requires failed/terminal status with no delivery. Admins can also queue refunds via the portal; the handler locks the payment, calls Stripe with an idempotency key, updates status, and sends refund_success or refund_failed_needs_help emails.

Partner APIs list requests scoped to their partner_id with fields id, status/status_detail, tier_code, source, created_at, delivered_at, and terminal_error_code. Target listings include target_index, job_title, and company_name. Resume content and cover letters are not exposed; resends create a new status token and email the applicant.

No off-site trackers are wired. Optional analytics posts to Supabase via /api/analytics, respects the DNT header, and does not set client cookies in the app shell.