feat(idm): administer typed identity relationships

docs/INTERFACE_PATTERN_MIGRATION.md

@@ -14,6 +14,9 @@ IDM owns effective identity-to-function facts and their governed lifecycle.
 | Function request/grant list | Governed work queue | Start or inspect a function change | Shared grid/loading/status/action slot, localized state and workflow vocabulary |
 | Request/grant editor | Guided consequential editor | Submit a governed assignment change | Shared segmented control/dialog/forms, guarded draft, effective dates, justification and evidence help |
 | Function-change detail | Decision and provenance record | Approve, reject, accept, request changes, withdraw, respond, or recover | Shared confirmation, available-action contract, retained actor/policy/workflow/history evidence |
+| Typed-group directory | Repeated administration | Create, edit, activate, or deactivate a tenant business group | Shared grid/card/dialog/action bar, optimistic revision, source and provenance fields, exact contextual help |
+| Effective relationship directory | Effective-dated administration | Create, change, expire, or irreversibly revoke a business relationship | Searchable identity/group selectors, four distinct lifecycle states, dirty guard, reasoned destructive confirmation |
+| Membership inspector | Point-in-time evidence reader | Resolve included and excluded identities for a group, time, and relationship kind | Shared resolver endpoint, localized time, decision codes, identity lifecycle explanation |
 | `idm.action.view-function-assignments` | Contextual cross-module action | Navigate with function context | Declared capability surface, permission guard, no Organizations-private import |
 
 ## Consequence And Availability Rules
@@ -32,6 +35,14 @@ IDM owns effective identity-to-function facts and their governed lifecycle.
   the governed record.
 - Deactivation and expiry remove a fact from effective resolution while
   retaining provenance and lifecycle evidence.
+- Future, active, expired, and revoked relationships remain visually distinct.
+  Revocation requires a reason, acts immediately, and leaves the record
+  immutable; later reuse requires a new relationship.
+- Typed relationship managers use searchable Identity and group references.
+  External source, revision, properties, and provenance remain inspectable and
+  editable under optimistic concurrency.
+- Membership inspection uses the production resolution capability and shows
+  excluded decisions instead of presenting only a flattened member list.
 - Missing permission, identity search, and organization functions identify the
   required action, responsible administrator, and destination.
 
@@ -43,9 +54,9 @@ dialogs retain focus containment and return behavior; stable grid actions remain
 keyboard reachable. Existing responsive CSS collapses summaries and histories
 to one column at narrow widths.
 
-English and German catalogues cover route metadata, assignment fields, governed
-states, workflow steps, decisions, confirmations, and accessible labels. Dates
-follow the selected platform locale. Manifest topics provide stable route,
-field, blocker, workflow, and consequence references without importing optional
-Policy, Audit, Notifications, Access, or Workflow Engine implementations.
-
+English and German catalogues cover route metadata, assignment and relationship
+fields, governed states, workflow steps, membership decisions, confirmations,
+and accessible labels. Dates follow the selected platform locale. Manifest
+topics provide stable route, field, blocker, workflow, lifecycle, provenance,
+and consequence references without importing optional Policy, Audit,
+Notifications, Access, or Workflow Engine implementations.

docs/TYPED_RELATIONSHIPS.md

@@ -41,6 +41,26 @@ The existing IDM lifecycle worker claims an elapsed relationship and records its
 event marker in the same transaction. Repeated or concurrent sweeps therefore do
 not publish duplicate expiry events.
 
+## Administration workspace
+
+The `/idm` workspace exposes typed groups and effective relationships to users
+with `idm:relationship:read`. Mutations require `idm:relationship:write`; the
+write permission also permits the identity search used by the subject and
+related-identity selectors without broadening read-only relationship access.
+
+Group and relationship editors retain external provider, resource, revision,
+property, and provenance values. Updates carry the loaded optimistic revision,
+so a stale editor receives a conflict instead of overwriting another
+administrator's change. The relationship directory distinguishes future,
+active, expired, and revoked states from the validity window and lifecycle
+record. Revocation requires a reason, takes effect immediately, and leaves the
+record immutable as evidence.
+
+The membership inspector accepts an effective time and one or more relationship
+kinds. It shows both included and excluded decisions with stable reason codes
+and identity lifecycle state. This is the same resolution contract used by
+downstream consumers; it is not a preview with different semantics.
+
 ## Distribution Lists
 
 When Distribution Lists is enabled, an `idm_group` entry resolves through this
@@ -48,4 +68,3 @@ capability. Every effective identity becomes an internal-mail candidate when an
 active linked account exists. Every rejected relationship remains visible in the
 expansion evidence with a stable reason code. Distribution Lists stores only the
 provider reference and frozen expansion evidence, not IDM records.
-