Relationships
#1884 Genesis "New Blood" (recruit_first) only counts collective invites — a platform invite can never complete it
Opened by keeb · 8/28/2026· Shipped 8/28/2026
The Genesis challenge New Blood (recruit_first, 1,000 XP — the heaviest single challenge in the pass) is wired exclusively to the COLLECTIVE invite lane. An invite sent through POST /api/v1/invites (the platform lane) can never complete it, no matter what happens afterwards.
Symptom
https://swamp-club.com/u/sntxrr/genesis shows CREW 0/1, New Blood unchecked, even though sntxrr sent a platform invite that has now been accepted and bound — the invite is status: accepted with inviteeId set as of 2026-08-28T00:51:16Z (the repair shipped with #1880).
Root cause
lib/app/quest/genesis-progress-projection.ts:
case "recruit_first":
return c.invitesLanded >= 1; // :117-118
...
invitesLanded: eventTotal("collective_invite_landed"), // :319invitesLanded counts one event type, and the platform lane never emits it. That lane emits:
| event | owner | when |
|---|---|---|
platform_invite_sent |
inviter | at send |
platform_invite_accepted |
invitee | at claim/bind |
platform_invite |
inviter | only at the tier-gated payout |
None of them is collective_invite_landed, so New Blood stays 0/1 forever for a platform invite — including after the recruit reaches the reward tier, since the payout emits platform_invite (XP + the First Rule badge), which the quest projection does not read.
The catalog copy is lane-agnostic — lib/quest-catalog.ts:579-584 reads "invite someone who accepts" — so the challenge presents as covering both lanes while only one is counted.
Trap for whoever fixes this
Do not simply add platform_invite_accepted to invitesLanded. That event is invitee-owned (its distinct_id is the recruit), so eventTotal would credit the person who accepted the invite rather than the person who sent it — silently awarding New Blood to the wrong operative.
Suggested fix
Mirror what the collective lane already does at lib/app/claim-pending-invitations.ts:248: emit an inviter-owned event at bind time — platform_invite_landed — from claimPlatformInvites, and count it alongside collective_invite_landed in invitesLanded. That keeps the challenge meaning "someone accepted your invite" rather than letting it drift into "your recruit reached tier 5".
Since sntxrr's invite is already bound in prod, the challenge should light on the next Genesis recompute once the event exists (note GENESIS_CATALOG_VERSION invalidation only covers catalog changes, so backfilling the event for the already-bound invite may need its own step).
Related
- #1880 — the platform invite never bound at all (fixed, PR #1153). This is the second half: even once bound, the quest does not count it. Both had to be wrong for the inviter to see nothing.
Shipped
Click a lifecycle step above to view its details.
Sign in to post a ripple.