Teammates
Invite people, review membership, manage access and transfer Workspace ownership.
/admin/settings/teammatesFuture Spec 03 →Current-state summary
The Settings Teammates page resolves two active Membership rows, no pending invitations, no Teams and five Role Labels. It provides Workspace ownership transfer, invitation entry, metrics, search/filter/sort behavior, Export and Columns. The active Workspace still carries Proper Gallery seed identity, and the Custom roles metric incorrectly describes Role Labels as authority-bearing roles.
Interface inventory
Anatomy and verified behavior
Verification states separate observed behavior from requirements or assumptions.
| Element | Current behavior | Verification |
|---|---|---|
| Attention metrics | Active teammates 2, pending invitations 0, Teams 0 and Custom roles 5. | Verified live; Custom roles terminology is incorrect |
| Membership grid | Teammate, Roles, Teams, Access level, Job title, Access and Actions with twelve sort options. | Verified live |
| Current rows | Demo Administrator is Owner; [email protected] is Administrator and carries Administrator as both label and access-level wording. | Verified live |
| Administrative actions | Transfer ownership and Invite teammate are visible; no mutation was performed. | Visible only |
User journeys
Current flows
Invite teammate
- Open Teammates
- Select Invite teammate
- Enter identity
- Choose Access Role and optional Role Labels
- Send expiring invitation
- Resolve acceptance into one Membership
Transfer ownership
- Select Transfer ownership
- Choose eligible active Membership
- Require recent authentication and confirmation
- Transfer atomically
- Notify and audit
State model
Current and expected states
Metrics initially resolve from zero while the table loads.
Two current rows.
Metric exists at zero.
Not evidenced.
Product rules
Non-negotiable boundaries
- User identity, Workspace Membership, Access Role, Role Label and Team are separate records.
- Exactly one active Owner must remain.
- Role Labels never grant access.
- Invitations are expiring, revocable and email-bound.
- Ownership transfer is atomic, recently authenticated and audited.
Known current limitations · 4 mapped
What is missing, broken or unverified
Future Spec 03 owns closure →- Legacy Proper Gallery identity remains.
- Custom roles terminology conflates labels and authority.
- Invitation lifecycle, suspension and removal were not verified.
- Cross-profile teammate counts have previously conflicted.
Future alignment
Required evolution
- 01Implement Spec 03 correction contract.
- 02Rename Custom roles to Role Labels.
- 03Use one Membership-backed identity and count everywhere.
- 04Register invitation, acceptance, expiry, revocation, access-change and ownership events.
Current baseline
Acceptance record
- Two live Memberships are documented.
- No administrative mutation was performed.
- Role Labels are never presented as permission grants.
- One canonical Membership set powers every count and picker.
Reverse-spec completeness
Documentation coverage
The interface is still changing, so visual evidence and repository tracing remain intentionally incomplete.
Purpose and user outcome
DocumentedRoles and access
DocumentedRoutes and entry points
DocumentedPage and component anatomy
DocumentedFields and displayed data
DocumentedPrimary actions
DocumentedForms and validation
DocumentedStates and transitions
DocumentedEmpty, loading and error states
DocumentedResponsive behavior
PartialAccessibility behavior
PartialActivity and audit events
PartialData sources and persistence
DocumentedNotifications and automation
PartialKnown defects and limitations
DocumentedReusable component dependencies
DocumentedFuture-spec conflicts
PartialVisual and repository evidence
DeferredAcceptance of current baseline
Documented