- Shipped
- September 7, 2026 at 8:25 AM UTC
- Author
- Kamo
- Commit
- dadd9af
Twenty-six of the thirty-five are questions the database can already answer, so they are awarded by asking it. SingleActionProbes holds one EXISTS per achievement — what "has this member done it" MEANS, in one reviewable file rather than scattered as derived queries across twenty repositories in the shared library, where the next reader has no idea any of them is load-bearing. THE READ PATH IS THE BACKFILL. These were true before the catalogue existed, so the first achievements read after this ships awards every member everything they had already done. Nothing to run, no migration. Probes are skipped once the member holds the achievement — it is never revoked, so held is a permanent answer and re-asking can only cost — and each runs in its own try/catch, so a renamed column costs one badge rather than an achievements page that awards nothing. EVERY PROBE WAS EXECUTED AGAINST THE LIVE SCHEMA BEFORE SHIPPING, which is the only reason four of them work. As written and reviewed they all looked correct: TAKE_A_SEAT required meeting_participants.joined_at, which is NULL on all 283 live rows because nothing writes it. Permanently unearnable. WORTH_KNOWING compared contacts.owner_id to a member id. It is a USER id. MAKE_IT_YOURS keyed user_backgrounds on member_id, which the upload path leaves null; the row is keyed by user. STAKE_YOUR_CLAIM used primary_agent_member_id, which is null on most SEE_IT_THROUGH reservations. The requester is the one who gets the lock. Each was a badge that would have sat locked forever with nothing in any log to say why. A census across every member now credits 336 member-achievements on first read, from 83 members with a photo down to 1 who has closed a locked opportunity. Five probes answer zero and that is correct — nobody has confirmed 2FA, filled a picture frame, had an idea seconded, taken a free-for-all lead, or uploaded a wallpaper yet. The other nine are awarded through two guarded paths. /internal/achievements/event is server-to-server behind X-Internal-Auth and refuses anything not EVENT; /achievements/self/claim resolves the member from the SESSION and refuses anything not CLIENT. Neither can reach a counted track however good its credentials, which is what the trigger kind is for.