Send a new starter to the board, and open the advert they came for

Featurekamo-internal
Shipped
September 5, 2026 at 11:51 PM UTC
Author
Kamo
Commit
105ef83

A team member whose employment is not ACTIVE is already confined to the restricted tier, and the home screen already bounced them somewhere. It now matters WHERE: everybody whose employment has not STARTED is in that tier too — a candidate who registered from a job advert is PROSPECT — and Careers is the one page they came here for. So the destination splits. From the home screen: the careers tab. From anywhere else: their own compliance record, exactly as before. That second half is the destination for a former employee bounced off a page they may no longer open, and routing those to a job board instead would be both useless and tactless. The choice is a pure function in capabilities.ts rather than an expression in the guard, so a test can pin it. Getting it backwards puts a terminated employee on a hiring page and a new starter on paperwork they have not been given, and neither would ever be reported as a bug. The careers tab now also renders for a non-ACTIVE team member regardless of rights. Not a loosening so much as the gate catching up with where the product sends people: they hold no rights at all, because rights arrive with a role and a role arrives with the job, so a rights-only gate would land the redirect on a page with no careers tab on it. CareersAccess.requireView carries the same three-way test, and remains the thing that actually authorizes. The advert opens from the BOARD now, not from a cookie. The uid is on the member's own record and the flag is lowered server-side, so the prompt is spent by an ANSWER — the application was completed, or the dialog was closed — rather than by a page load. Under a cookie a refresh mid-form meant the candidate never saw it again. While that prompt is up the dialog refuses a backdrop click and Escape. It is their one chance to apply to the role they came for, and a stray click must not be what spends it. The close button still works in every mode, deliberately: a dialog with no way out is a trap, and somebody who does not want to apply right now has to be able to say so. A completed application spends the prompt without waiting for the close. Someone who reads the confirmation and then shuts the tab has unambiguously answered, and re-prompting them for a job they have already applied to would be absurd. The claim-token handoff goes with applying-without-an-account.

All changes

Like what you see shipping?

Every one of these updates lands in your workspace automatically. Start free and watch it grow week after week.

Start Free ForeverView Pricing