[thomgabriel]

Kuka asked for a form on our site for the new Superteam x Helius perk. Builders sign in, tell us their name, WhatsApp, project name, a summary and where they would use Helius; the team vets each one by hand and sends the activation code.

Same shape as the startup form: one application per person, editable afterwards, name and WhatsApp saved on users, e-mail from the login. A first-time applicant who already described a project starts with it filled in, from the startup form if there is one, else from "Sobre você", both fields from the same source. Global admins get a "Perks" card on /admin with the count and a CSV download (paginated past the 1,000-row cap). First application fires perk_applied and an RD conversion global_2026_perk_helius.

Migration 00068 is already applied to production (additive table). RLS was checked by impersonation: own row readable and editable, another user's row invisible and not writable, anon refused. The table revokes everything from authenticated before granting select/insert/update, because the default privileges also grant DELETE and TRUNCATE; the rest of the schema has the same TRUNCATE grant, which is out of scope here.

Tested end to end at 390px with a throwaway account (deleted): signed-out hero, validation errors, send, confirmation, edit, admin CSV, 403 for non-admins. 267 unit tests pass.

The tier copy (Developer 1 year, Business 3 months) comes from the brief Kuka shared; it lives in constants.ts for edits.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
hackathon-platform	Ready	Preview	Oct 15, 2026 3:53pm UTC

[claude]

Claude finished @thomgabriel's task in 22s —— View job

---

Verdict: safe to merge. No findings.

I checked the diff against CLAUDE.md in the priority order given:

• Authorization:
  • applyForHeliusPerk gates on requireUser() and writes only with the user-scoped client.
  • The CSV route gates on requireAdmin(), returning 401 or 403, before it opens the service-role client.
  • The /admin Perks card shows only for global admins, so scoped organizers don't see it.
  • The migration revokes DELETE and TRUNCATE from authenticated and anon and sets RLS to own-row for select, insert and update. The upsert on perk,user_id fits those policies.
• Data safety:
  • Query errors go through logQueryError or unwrap, and prior uses .maybeSingle().
  • The migration is a new table with no existing function changed. It isn't re-runnable (no IF NOT EXISTS), but it's already applied to production.
  • The CSV export pages past the 1,000-row cap with a stable order (created_at, then id).
  • toCsv neutralizes formula-leading cells for the user-supplied text.
• Correctness:
  • redirect() comes after the tracking and RD calls, and ?enviado=1 is a fixed path with no user-controlled next.
  • The first-application check keeps edits from re-firing perk_applied and the RD conversion.
  • Dates go through formatBrt from src/lib/dates.ts.
• Analytics: server capture uses track() with the documented perk_applied event, and docs/TRACKING.md is updated. I didn't trace whether the event carries edition; perks aren't tied to an edition. The RD identifier is registered in RD_CONVERSION_IDENTIFIERS.
• Conventions: copy is pt-BR, and the code and git text are English. The page is under (public), so the force-dynamic rule doesn't apply. I added no comments of my own, and I didn't audit the page and form for brand tokens.

I didn't run the tests or the build.

One small thing that doesn't meet the bar for a finding: if the prior lookup errors (it's only logged), an edit is treated as a first application and fires perk_applied and the RD conversion again. That needs a transient read failure right before a successful write.
· branch feat/helius-perk-form

[claude]

Claude finished @thomgabriel's task in 18s —— View job

---

Verdict: safe to merge. No findings.

I re-checked the diff after the new commit (f0b4e36) against CLAUDE.md. I did not run the tests or the build.

• Authorization:
  • applyForHeliusPerk gates on requireUser() and writes only with the user-scoped client.
  • The CSV route gates on requireAdmin() before it opens the service-role client.
  • The /admin Perks card is hidden from scoped organizers.
  • The migration revokes DELETE and TRUNCATE from authenticated and anon. RLS is own-row for select, insert and update.
• Data safety:
  • Query errors go through logQueryError or unwrap, and the prior lookup uses .maybeSingle().
  • The CSV export pages past the 1,000-row cap with a stable order.
  • The migration is additive and already applied.
• Correctness: redirect() comes after tracking and the RD call. The ?enviado=1 target is fixed. The first-application check keeps edits from re-firing perk_applied and the RD conversion.
• Analytics: perk_applied and the RD identifier match docs/TRACKING.md. Perks aren't tied to an edition, so the event carries no edition.

One thing that isn't a finding: if the prior lookup fails, it's only logged. An edit would then count as a first application and fire the event and RD conversion again. That needs a read failure right before a successful write.
· branch feat/helius-perk-form