REL-CAP-ROL: Capability ↔ Role

Stable ID: REL-CAP-ROL
Entities: CAP (Capability) ↔ ROL (Role)
Relationship status: implemented

Audited relationship

Role-capability joins and the canonical role ladder are current.

Design

Roles bundle Capabilities. Cardinality: M:N via the role_capabilities join (composite PK (role_id, capability_id)). One Role bundles many Capabilities; one Capability appears in many Roles. The six canonical Roles form a strict-subset ladder (owner ⊃ admin ⊃ superuser ⊃ member ⊃ contributor ⊃ guest) — each rung's bundle is a subset of the rung above (see development/permission-model.md §6). The owner Role bundles the full release-current Capability catalogue; guest bundles none. This is the core edge of the permission model — everything else (Human → Capability, Group → Capability) is transitive through this one.

Implementation

role_capabilities table, composite PK (role_id, capability_id). getRoleCapabilities(roleId) returns the bundle for a single Role.

Six canonical Role rows per Server (owner, admin, superuser, member, contributor, guest) with UNIQUE (slug). seedTrustPersonal upserts via ON CONFLICT (slug) DO NOTHING and seeds role_capabilities via ON CONFLICT DO NOTHING on (role_id, capability_id). Retired slugs: write_shared_memory → split into read_memories + manage_memories; approve_shared_memory → folded into approve_destructive_actions. Retired Role slugs: household, teammate, and the stranger sentinel — non-members resolve to guest.

Verification state

This article remains at the original relationship granularity for AI and maintainer use. Its current-versus-target classification was reconciled before migration; public code-anchor verification remains in progress against Nautilo 4b3ea604.