- Shipped
- September 5, 2026 at 11:47 PM UTC
- Author
- Kamo
- Commit
- 194999c
Registration on the /team path now accepts appliedJobId — the uid kamo-register parked when the careers board sent the candidate to /team?jobId= — and writes it onto the new TEAM_MEMBER as recentlyAppliedForId, with isShowAppliedForApp raised. The workspace reads both to open that advert's application form the first time they arrive. Parsed leniently and never fatal. The value arrives from a cookie written by another host and is worth exactly one thing; failing a registration over a mangled link would trade an account for a convenience. TeamMemberActivationNotifier sends the welcome when employment becomes ACTIVE. It is one class rather than an if at each writer because the decision is a TRANSITION, not a state: the member profile page re-saves every field on every edit, so "the status is ACTIVE" is true on thousands of saves that changed a phone number. Only a comparison with the previous value tells those apart, and it has to be made in one place to be made correctly in both. Both call sites read the previous status BEFORE their own write and hand it in. MemberController fires after the save, so a welcome is never sent for a change that failed to commit; MemberCreationService passes null, which is literally true for a member created straight into ACTIVE. The recipient is the address on the USER account, never the work mailbox. At the instant this fires the work mailbox may not be provisioned, and the entire content of the message is "you can sign in now" — sending that to an inbox they cannot reach until they sign in is a closed loop. **************** has to be applied by hand; InitializerService is not deployed.