Organization team management

The first admin becomes the owner of the initial organization. After login, you can read the current organization context, switch to an organization already visible to the current session, inspect members and invitations, and manage members with an owner or admin role.

These operations require a valid product session. HTTP/API requests use the login cookie or an authorization header. The CLI reads equivalent session input from APPALOFT_AUTH_COOKIE or APPALOFT_AUTHORIZATION; do not write those values to shell history, CI logs, repository files, issues, or pull request comments.

appaloft organization context
appaloft organization switch org_second

The command returns safe metadata for the current user, current organization, current role, selectable organizations, and configured login methods. Output does not include session tokens, cookies, OAuth provider tokens, invitation secrets, or raw deploy-token values. The switch command only selects organizations already visible to the current product session; selecting the current organization again is idempotent.

appaloft organization members list --organization-id org_self_hosted
appaloft organization invitations list --organization-id org_self_hosted --status pending

Member lists return member ids, safe user metadata, roles, joined timestamps, and similar safe fields. Invitation lists return safe invitation metadata without raw invitation tokens.

appaloft organization member invite --organization-id org_self_hosted --email [email protected] --role developer
appaloft organization member role mem_operator --organization-id org_self_hosted --role admin
appaloft organization member remove mem_operator --organization-id org_self_hosted

Available roles are owner, admin, developer, billing, and viewer. Owners and admins can manage members. Early self-hosted builds adapt the auth runtime's default member role back to Appaloft developer until richer custom role persistence is available.

Role updates and member removal keep at least one owner in the organization. If an operation would leave no owner, Appaloft rejects it instead of leaving the organization unrecoverable.

The same operations are available through HTTP/API:

GET /api/organizations/current-context
POST /api/organizations/current-context/switch
GET /api/organizations/{organizationId}/members
GET /api/organizations/{organizationId}/invitations
POST /api/organizations/{organizationId}/invitations
POST /api/organizations/{organizationId}/members/{memberId}/role
DELETE /api/organizations/{organizationId}/members/{memberId}

HTTP/API routes and CLI commands execute the same Appaloft operations. The auth runtime is an implementation detail; callers do not need, and should not depend on, underlying auth routes, tables, or provider payloads.

The Web console /organization page can read the current organization context, switch to another visible organization, inspect members and invitations, invite members, update roles, remove members, and manage deploy-token create, rotate, and revoke actions. Browser-driven self-hosted auth e2e coverage remains later Phase 8 work.

• For 401 product_auth_missing, log in again or provide a trusted session handoff to the CLI.
• For 403 product_auth_forbidden, confirm that the current user belongs to the target organization. Member management and deploy-token management also require an owner or admin role.
• If a member cannot be removed or demoted, check whether that member is the last owner.
• Do not edit auth database tables directly to bypass member, role, or invitation state; use CLI/HTTP/API or restore from a trusted backup.