A per-member-type default home screen

Featurekamo-internal
Shipped
August 28, 2026 at 7:31 PM UTC
Author
Kamo
Commit
e531440

A security model now says where each of its three member types lands when they open "/". Two values: HOME_SCREEN_DEFAULT is the launchpad everybody has always had, and REQUIRES_CHILD_ORG_OWNERSHIP withholds it until that member owns an organization of their own — "/" goes to /network/create instead, and the organization-network link leaves the top bar until they have one. Three columns rather than one, mirroring APPLIES_TO_MEMBERS / _TEAM_MEMBERS / _OWNERS, because the same model routinely wants a plain member pushed into creating their own organization while its team members and owners go to work. The rule is pure and tested in app/lib/homeScreenGate.ts: which column applies, and what counts as owning an organization (an owner of the org they are already inside has not created one — the same exclusion FirstOrgCta makes). It fails OPEN at every step. Only the exact string closes the gate; a null column, an unrecognised value, a failed applied-model fetch and an unreachable my-networks all read as "no", because taking somebody's home screen away on the strength of a request that did not answer is not something to do. One context, mounted above the navs and the page, rather than the hook in both places: NavTop and the launchpad need the same answer on every page load, and two copies would cost two round trips and could disagree for the length of one. The launchpad deliberately does not wait on it — holding every member's home page behind an /applied-model fetch to spare a handful of them a brief flash is the wrong trade.

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