Onboard the caller

Scaffold the calling account and the caller's personal workspace: the account's shared root, the caller's own private root, their directory row, their groups, and the account membership every other read is gated on.

This is the first call a new caller makes. Before it, the caller holds no account membership, so every account-scoped read answers 403 and the caller has no workspace to create anything in.

It also installs the deployment's extensions, in dependency order, for any of them this account does not have yet — firing each one's pre_install gate and seeding post_install hook under your bearer, exactly as POST /apps/{app}/install does. On a brand-new account that is the whole set; on an existing one it is usually none, so a repeat onboard fires no install hooks at all. An account whose installs were interrupted completes on its next onboard.

Idempotent. A repeat call re-reads what exists and answers 200 with the same assets and is_created: false. It also re-asserts the caller's access relationships, so a relationship lost to a partial earlier run heals on the next call rather than needing repair.

The caller's role on the shared root is admin for whoever created the account and member for everyone after them, and a re-onboard preserves whatever the roster says — a caller whose role was changed is not restored to admin by signing in again.

A machine identity may not call this, and gets 403. Account membership is held by people; a service account, an agent's own identity and an action identity each already hold whatever seats they were granted where they were provisioned. A token carrying no user_id claim, such as one an OAuth client minted with client_credentials, is a machine identity here too, whether or not the registry knows the client.