- Shipped
- September 7, 2026 at 6:41 AM UTC
- Author
- Kamo
- Commit
- 1160e3c
**************** counts a member's APPROVED Growth Hub submissions and settles their SPREAD_THE_WORD level against that count. It RECOUNTS rather than being told a number. The count is read here on every call — including the one MediaService makes when an admin approves — because a total supplied by a caller is a number this service cannot check, on an endpoint reachable by anything holding the cluster secret. One indexed aggregate makes a member's standing exactly as true as the Growth Hub's own tables. Called from BOTH the approval seam and every achievements read, the same shape `ensureBaseline` already uses and for the same two reasons. The approval seam is what puts the celebration in the same moment as the decision; the read is what covers every member who completed missions before this achievement existed, every approval whose cross-service call was dropped, and any future path that approves a submission without knowing this rule exists. There is no backfill and there is nothing to run. `AchievementInternalController` is that seam: POST **************** X-Internal-Auth compared in constant time against **************** fail-closed when the secret is unset — the same model as **************** It takes {orgId, memberId} and nothing else, so the worst a caller can do with it is cause a member to be credited for work that member has actually had approved. Idempotent, because award() SETS the running total rather than adding to it; and safe to lose, because the read path recounts anyway. The pending queue now orders by level within a timestamp — see the shared-library commit. With a nine-level track in the catalogue, a member catching up several levels in one recount would otherwise have been congratulated in an arbitrary order.