Access and roles
Workspace membership (read · contribute · maintain · admin), the Access tab, and invite-via-grant — without inventing org/teams.
SEIF already has a dual-layer membership model
(MEMBERSHIP-RESOLVER-v1). Extension roles and workspace grants resolve to the
same ladder. There is no org/teams layer in v1 — invite means grant a
principal a role on the workspace.
Role ladder
| Role | Can do in Hub |
|---|---|
read | View Work / Memory; no + Propose |
contribute | Draft and sign; create memory, seed, session, pending, memo |
maintain | Everything contribute can + Approve (ratify) decisions |
admin | Grants and workspace administration |
Actionable errors: if Propose or Approve fails for role, ask an owner for
contribute or maintain — do not expect a separate “invite email” product.
Access tab (live grants)
- Open the workspace Hub → Access.
- Owner/admin picks a principal and grants
read/contribute/maintain/admin. - The UI calls the engine membership API (
POST …/grants). - Production lists live engine grants — not demo fixtures.
The grantee signs in with the same identity (OAuth email / linked principal). Revoke or change role from the same tab.
Pod grants
Workspace Access is the production path for team invites. Pod-level grant UI may still show limited/fixture behavior — do not treat pod Access as the primary teammate invite flow yet.
Authoring gates (what the UI enforces)
| Action | Minimum role |
|---|---|
+ Propose (draft/sign creates) | contribute |
| Approve / ratify a decision | maintain |
| Cycle close-ritual | CLI/IDE (not Hub) |
Classification (related)
Default artifact class is INTERNAL (syncs with the team). CONFIDENTIAL stays local — do not put patient/client secrets in shared Memory. Classification only escalates.
See also
- Hub without CLI
- Web first touch
- Engine roles source:
seif-engineworkspace_roles.py(read | contribute | maintain | admin)