feat: add registration access ui contracts

docs/contracts.md

@@ -30,6 +30,19 @@ HTTP or RPC adapters should preserve these operation names:
   `accept_family_invitation`
 - `audit_records`, `outbox_events`
 
+## UI Contract Surface
+
+`RegistrationAccessManagementUi` is the optional UI-facing contract facade for
+registration and access management. It returns screen/view models and route
+definitions over `UserEngineService`; transport adapters may serve those as
+HTTP, RPC, desktop, CLI, or rendered HTML.
+
+The facade covers self-service registration, factor status, terms/consent,
+prepared-rights review and claim, active hat selection, admin diagnostics, and
+accessible HTML verification. It does not handle credential entry, MFA
+challenges, token issuance, hidden policy decisions, notifications, or
+service-specific admin consoles.
+
 ## Registration Contract
 
 Registration is a headless user-entry facade. It creates a

docs/hats-realms-services-assets-access-profiles.md

@@ -103,4 +103,4 @@ proofing data.
 - Approval workflows for privileged hats remain a later slice.
 - Access profile profile-default values are carried into active context and
   projections, but this slice does not persist them as catalog profile values.
-- UI selection flows are left to USER-WP-0014.
+- UI selection flow contracts are implemented by USER-WP-0014.

docs/netkingdom-registration-onboarding-vision.md

@@ -235,9 +235,9 @@ once.
 
 ## Recommended Workplans
 
-As of 2026-06-15, `USER-WP-0010`, `USER-WP-0011`, `USER-WP-0012`, and
-`USER-WP-0013` are implemented as headless user-engine slices. The later
-workplans remain recommended follow-on work.
+As of 2026-06-15, `USER-WP-0010`, `USER-WP-0011`, `USER-WP-0012`,
+`USER-WP-0013`, and `USER-WP-0014` are implemented as user-engine slices. The
+later security-conformance workplan remains recommended follow-on work.
 
 | Workplan | Title | Purpose |
 | --- | --- | --- |

docs/onboarding-journeys-and-welcome-protocols.md

@@ -88,4 +88,4 @@ gap identifiers.
 - No notification platform or support-content renderer is implemented.
 - No protected subsystem tour is hard-coded into user-engine.
 - External task and callback execution is left to adapters.
-- UI surfaces are left to USER-WP-0014.
+- UI surface contracts are implemented by USER-WP-0014.

docs/registration-and-access-management-ui.md

@@ -0,0 +1,128 @@
+# Registration And Access Management UI
+
+Status: implemented headless UI contract slice
+Date: 2026-06-15
+Related workplan: USER-WP-0014
+
+## Purpose
+
+This slice adds an optional NetKingdom registration and access-management UI
+contract over the headless `UserEngineService`. It is not a credential UI and
+does not own browser state. It provides transport-neutral screen models,
+route contracts, and an accessible HTML renderer that web, desktop, or CLI
+adapters can serve.
+
+## Information Architecture
+
+The implemented UI facade exposes these primary areas:
+
+- registration
+- prepared rights
+- active hat
+- profile
+- onboarding
+- admin
+
+The supported views cover registration start/resume, factor status,
+registration completion, prepared-account review and claim, active hat
+selection, onboarding status, admin prepared accounts, admin access profiles,
+and admin onboarding diagnostics.
+
+## Public Facade
+
+`RegistrationAccessManagementUi` lives in `user_engine.ui` and is exported from
+`user_engine`.
+
+It exposes:
+
+- `information_architecture()`
+- `api_contract()`
+- `start_registration(...)`
+- `attach_factor(...)`
+- `complete_registration(...)`
+- `registration_screen(...)`
+- `prepared_rights_review(...)`
+- `accept_prepared_claim(...)`
+- `deny_prepared_claim(...)`
+- `hat_selection_view(...)`
+- `select_hat(...)`
+- `admin_dashboard(...)`
+- `render_html(...)`
+
+## Route Contract
+
+The UI route contract maps thin transport routes to existing headless service
+facades:
+
+- `registration.start` -> `start_registration`
+- `registration.factor` -> `attach_registration_factor`
+- `registration.complete` -> `complete_registration`
+- `prepared_account.review` -> `list_prepared_accounts`
+- `prepared_account.accept` -> `claim_prepared_account`
+- `prepared_account.deny` -> UI dismiss decision
+- `access_profile.select_hat` -> `select_active_hat`
+- `admin.dashboard` -> diagnostics/list views
+
+Proofing, IAM, authorization, notification, and protected service consoles
+remain adapter boundaries.
+
+## Registration Flow
+
+The self-service UI facade can start registration, attach adapter-supplied
+factor evidence, show safe factor status by type, enforce UI terms/consent
+before completion, and show the resulting NetKingdom ID.
+
+Factor values are never rendered. The flow displays factor types and status,
+not email addresses, phone numbers, postal addresses, eID payloads, provider
+tokens, or challenge material.
+
+## Prepared Rights
+
+Prepared-account review displays pending packages by id, display name,
+required factor types, entitlement kinds, and status. Required factor values
+are redacted. Accepting a package calls `claim_prepared_account`. Denying a
+package is an explicit UI dismiss state and does not mutate prepared-account
+domain state.
+
+## Hats And Active Context
+
+The active-hat view lists access profiles and the current active context.
+Selecting a hat calls `select_active_hat`; the domain service still enforces
+tenant, membership, factor, approval, and authorization rules. The UI does not
+display hidden policy logic or final authorization decisions.
+
+## Admin Surface
+
+The admin dashboard composes existing diagnostics and list operations:
+
+- registration diagnostics
+- tenant diagnostics
+- prepared-account counts
+- access-profile counts
+- onboarding diagnostics
+
+The dashboard intentionally reports counts and lifecycle gaps without exposing
+factor values, prepared-account factor matches, profile default values, claim
+values, or raw proofing payloads.
+
+## Accessibility And Layout
+
+The renderer emits semantic landmarks:
+
+- `banner`
+- `navigation`
+- `main`
+
+Sections are linked from navigation, action controls expose `aria-label`, and
+mobile/desktop layout metadata is available through the screen model. Mobile
+screens use one column with a 44px minimum touch target; desktop screens use a
+two-column workbench layout.
+
+## Current Limits
+
+- This slice does not ship a web server, JavaScript client, or CSS bundle.
+- Browser persistence is not authoritative over domain state.
+- The HTML renderer is a verification artifact and adapter starting point, not
+  a final branded application.
+- Credential entry, password reset, passkeys, MFA challenges, token issuance,
+  notifications, and service-specific consoles remain outside user-engine.

docs/registration-identity-and-factor-model.md

@@ -115,5 +115,6 @@ return factor values.
   `docs/hats-realms-services-assets-access-profiles.md`.
 - Welcome protocols and onboarding journeys are implemented by USER-WP-0013
   and documented in `docs/onboarding-journeys-and-welcome-protocols.md`.
-- Registration UI is left to USER-WP-0014.
+- Registration UI contracts are implemented by USER-WP-0014 and documented in
+  `docs/registration-and-access-management-ui.md`.
 - Provider-backed proofing and credential flows remain external adapters.

docs/ui-contracts.md

@@ -3,11 +3,26 @@
 Future self-service and scope-admin UIs should consume user-engine through a
 transport adapter that preserves the service shapes below.
 
+USER-WP-0014 adds `RegistrationAccessManagementUi` as the first implemented
+headless UI contract facade. It returns transport-neutral screen models,
+route definitions, responsive layout metadata, and an accessible HTML
+verification renderer.
+
 ## Self-Service Account UI
 
 Required backend operations:
 
 - `me` to resolve the current actor, user, account, and identity links.
+- `RegistrationAccessManagementUi.start_registration` to create a UI-backed
+  registration session.
+- `RegistrationAccessManagementUi.attach_factor` to attach adapter-supplied
+  factor evidence without rendering factor values.
+- `RegistrationAccessManagementUi.complete_registration` to enforce UI
+  terms/consent and complete the headless registration flow.
+- `RegistrationAccessManagementUi.prepared_rights_review` and
+  `accept_prepared_claim` to review and claim prepared rights.
+- `RegistrationAccessManagementUi.hat_selection_view` and `select_hat` to show
+  available hats and select active access context.
 - `effective_profile` with the actor tenant and optional application id.
 - `projection` with `SELF_SERVICE` for editable user-visible fields.
 - `set_profile_value` for fields whose catalog mutability includes `USER`.
@@ -19,11 +34,37 @@ Required backend operations:
 Required backend operations:
 
 - `resolve_tenant_context` before all tenant-scoped screens.
+- `RegistrationAccessManagementUi.admin_dashboard` for registration,
+  prepared-account, access-profile, and onboarding diagnostics.
 - `set_tenant_account_status` for in-scope account state.
 - `add_membership` for tenant/team membership changes.
 - `projection` with `ADMIN` or a future admin transport projection.
 - `tenant_diagnostics` for onboarding and support readiness checks.
 
+## UI Route Contract
+
+`RegistrationAccessManagementUi.api_contract()` defines these route ids:
+
+- `registration.start`
+- `registration.factor`
+- `registration.complete`
+- `prepared_account.review`
+- `prepared_account.accept`
+- `prepared_account.deny`
+- `access_profile.select_hat`
+- `admin.dashboard`
+
+Transport adapters may map these ids to HTTP, RPC, desktop, or CLI routes.
+The route contract marks factor values, prepared-account factor matches,
+profile defaults, claim values, and hidden policy details as redacted.
+
+## Accessibility And Responsive Contract
+
+`render_html` emits `banner`, `navigation`, and `main` landmarks. Section
+navigation uses labels, controls expose `aria-label`, and screen models include
+mobile and desktop layout metadata. Mobile screens use a one-column layout and
+44px minimum touch target. Desktop screens use a two-column workbench layout.
+
 ## Fixtures
 
 Use `user_engine.testing.scenarios` for human, tenant admin, platform