generated from coulomb/repo-seed
Implement durable store contract and registration roadmap
This commit is contained in:
@@ -4,13 +4,13 @@ type: workplan
|
||||
title: "Postgres Durable Store Consumer Requirements"
|
||||
domain: netkingdom
|
||||
repo: user-engine
|
||||
status: proposed
|
||||
status: finished
|
||||
owner: codex
|
||||
topic_slug: netkingdom
|
||||
planning_priority: high
|
||||
planning_order: 9
|
||||
created: "2026-06-05"
|
||||
updated: "2026-06-05"
|
||||
updated: "2026-06-15"
|
||||
depends_on:
|
||||
- USER-WP-0007
|
||||
state_hub_workstream_id: "b5c85993-4aa2-4a8d-98b6-d174ab1b4538"
|
||||
@@ -22,9 +22,11 @@ state_hub_workstream_id: "b5c85993-4aa2-4a8d-98b6-d174ab1b4538"
|
||||
|
||||
Define, from the `user-engine` consumer perspective, what a durable
|
||||
Postgres-backed store must provide before user-engine depends on it in
|
||||
NetKingdom. This workplan is requirements-only: it should not implement the
|
||||
Postgres adapter, provision databases, create tenant infrastructure, or choose
|
||||
the final provider repository design.
|
||||
NetKingdom. The 2026-06-15 review also identified and closed one missing
|
||||
durable-store contract in this repository: `UserEngineService` now consumes an
|
||||
adapter-neutral store protocol instead of the concrete in-memory store. This
|
||||
workplan still does not implement the Postgres adapter, provision databases,
|
||||
create tenant infrastructure, or choose the final provider repository design.
|
||||
|
||||
## Scope Direction
|
||||
|
||||
@@ -51,7 +53,7 @@ schema, migrations for its own tables, store semantics, and conformance tests.
|
||||
|
||||
```task
|
||||
id: USER-WP-0009-T1
|
||||
status: todo
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "64c578e1-e2a1-48d4-8da9-659d4f881ef3"
|
||||
```
|
||||
@@ -64,7 +66,7 @@ schema version reporting.
|
||||
|
||||
```task
|
||||
id: USER-WP-0009-T2
|
||||
status: todo
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "19cfd23e-8a87-416d-b948-c727e8c5a11c"
|
||||
```
|
||||
@@ -76,7 +78,7 @@ security, observability, backup/restore expectations, and acceptance tests.
|
||||
|
||||
```task
|
||||
id: USER-WP-0009-T3
|
||||
status: todo
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "d3b388de-bb79-41d5-805e-d2def88ac926"
|
||||
```
|
||||
@@ -88,7 +90,7 @@ secrets, authorization, or audit-platform concerns.
|
||||
|
||||
```task
|
||||
id: USER-WP-0009-T4
|
||||
status: todo
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "d0e05af7-d777-4948-b072-79f1ffb9fc3a"
|
||||
```
|
||||
@@ -99,7 +101,7 @@ the isolated MVP without leaking Postgres concepts into domain code.
|
||||
|
||||
```task
|
||||
id: USER-WP-0009-T5
|
||||
status: todo
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "3c428960-be5b-411e-bd9b-7cba833abba8"
|
||||
```
|
||||
@@ -111,7 +113,7 @@ readiness, and redacted diagnostics.
|
||||
|
||||
```task
|
||||
id: USER-WP-0009-T6
|
||||
status: todo
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "d606094a-254c-46d5-9bb8-a3449ce61c2c"
|
||||
```
|
||||
@@ -133,10 +135,46 @@ expectations, encryption, and operational runbooks.
|
||||
tests.
|
||||
- The provider-repo boundary is explicit and avoids duplicating IAM, secrets,
|
||||
authorization, audit-platform, or infrastructure ownership.
|
||||
- `UserEngineService` depends on an adapter-neutral store protocol with
|
||||
readiness, query, transaction, audit, outbox, and diagnostics semantics.
|
||||
- No Postgres implementation code is added as part of this workplan.
|
||||
|
||||
## Expected Outputs
|
||||
|
||||
- `docs/postgres-durable-store-consumer-requirements.md`
|
||||
- Store-boundary notes suitable for a future provider repo.
|
||||
- `UserEngineStore` protocol and local-store conformance behavior.
|
||||
- Follow-up implementation workplan inputs for a Postgres adapter.
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
Implemented on 2026-06-15:
|
||||
|
||||
- Added `UserEngineStore` in `src/user_engine/ports.py` as the durable
|
||||
persistence boundary for service behavior.
|
||||
- Moved `UserEngineService` from the concrete in-memory store type to the
|
||||
store protocol.
|
||||
- Replaced service reads of local dict/list fields with protocol accessors for
|
||||
users, identities, applications, bindings, catalogs, audit, outbox, and
|
||||
diagnostics.
|
||||
- Added store transaction boundaries around mutating writes so domain changes,
|
||||
local audit records, and outbox events commit or roll back together.
|
||||
- Kept authorization-denial audit records durable without emitting outbox
|
||||
events, including when a denial happens inside a composed outer transaction.
|
||||
- Extended `InMemoryUserEngineStore` as the reference adapter with query
|
||||
helpers, record counts, pending outbox access, audit-log access, and nested
|
||||
transaction rollback semantics.
|
||||
- Added conformance tests for protocol-only store consumption, failed-mutation
|
||||
rollback, and denial-audit persistence across rollback.
|
||||
- Updated the durable-store and public contract docs to describe the new
|
||||
adapter boundary.
|
||||
- No Postgres adapter, database dependency, provisioning, credentials, or
|
||||
infrastructure ownership was added.
|
||||
|
||||
Verification:
|
||||
|
||||
```text
|
||||
make test
|
||||
Ran 42 tests in 0.134s
|
||||
OK
|
||||
```
|
||||
|
||||
125
workplans/USER-WP-0010-registration-identity-and-factor-model.md
Normal file
125
workplans/USER-WP-0010-registration-identity-and-factor-model.md
Normal file
@@ -0,0 +1,125 @@
|
||||
---
|
||||
id: USER-WP-0010
|
||||
type: workplan
|
||||
title: "Registration Identity And Factor Model"
|
||||
domain: netkingdom
|
||||
repo: user-engine
|
||||
status: proposed
|
||||
owner: codex
|
||||
topic_slug: netkingdom
|
||||
planning_priority: high
|
||||
planning_order: 10
|
||||
created: "2026-06-15"
|
||||
updated: "2026-06-15"
|
||||
depends_on:
|
||||
- USER-WP-0007
|
||||
- USER-WP-0009
|
||||
state_hub_workstream_id: "0d53560b-2b9d-442b-9328-4b2ce5c5bdae"
|
||||
---
|
||||
|
||||
# USER-WP-0010 - Registration Identity And Factor Model
|
||||
|
||||
## Goal
|
||||
|
||||
Define and implement the first headless registration domain slice for
|
||||
NetKingdom users. The slice should let user-engine start and complete a
|
||||
registration session, establish a stable NetKingdom ID, link verified external
|
||||
identities, record factor evidence, and return identity context without
|
||||
becoming an identity provider or factor-proofing service.
|
||||
|
||||
## Scope Direction
|
||||
|
||||
user-engine owns the registration-domain records and service facade. NetKingdom
|
||||
IAM, identity providers, eID providers, mail/SMS proofing, credential
|
||||
lifecycle, sessions, and tokens remain external adapter concerns.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Do not implement password, passkey, session, MFA, SMS, email, or eID proofing
|
||||
providers in user-engine.
|
||||
- Do not issue OIDC/SAML tokens.
|
||||
- Do not build the registration UI in this workplan.
|
||||
- Do not implement prepared account claiming, access profiles, or onboarding
|
||||
journeys beyond the hooks needed for later workplans.
|
||||
|
||||
## Tasks
|
||||
|
||||
```task
|
||||
id: USER-WP-0010-T1
|
||||
status: todo
|
||||
priority: high
|
||||
state_hub_task_id: "2a6c93de-e320-41e6-8930-7a4099c5757a"
|
||||
```
|
||||
|
||||
Define NetKingdom ID semantics. Decide whether the public NetKingdom ID is the
|
||||
existing `User.user_id`, an alias, or a separate mapped identifier. Document
|
||||
stability, visibility, privacy, and migration expectations.
|
||||
|
||||
```task
|
||||
id: USER-WP-0010-T2
|
||||
status: todo
|
||||
priority: high
|
||||
state_hub_task_id: "31ddb44e-b7d1-406e-9114-78c5e7f92478"
|
||||
```
|
||||
|
||||
Add registration session domain models and lifecycle states: started,
|
||||
factor_pending, factor_verified, completed, abandoned, expired, and rejected.
|
||||
|
||||
```task
|
||||
id: USER-WP-0010-T3
|
||||
status: todo
|
||||
priority: high
|
||||
state_hub_task_id: "7441f064-eb49-4e66-8c1d-a2626aae020c"
|
||||
```
|
||||
|
||||
Add identity factor and factor verification models for email, phone, postal
|
||||
address, eID, invite, and SSO identity evidence. Store assurance metadata and
|
||||
evidence references without storing secret proofing payloads.
|
||||
|
||||
```task
|
||||
id: USER-WP-0010-T4
|
||||
status: todo
|
||||
priority: high
|
||||
state_hub_task_id: "7057afda-d585-48cd-bac1-f0bd0f05fef5"
|
||||
```
|
||||
|
||||
Create factor verification adapter ports. The adapters should accept external
|
||||
proofing results and return normalized factor evidence for user-engine.
|
||||
|
||||
```task
|
||||
id: USER-WP-0010-T5
|
||||
status: todo
|
||||
priority: high
|
||||
state_hub_task_id: "f4f0da38-9810-45e7-ab4e-0619eb45b3c4"
|
||||
```
|
||||
|
||||
Implement a headless registration facade for start, attach verified factor,
|
||||
complete, abandon, and resume flows.
|
||||
|
||||
```task
|
||||
id: USER-WP-0010-T6
|
||||
status: todo
|
||||
priority: medium
|
||||
state_hub_task_id: "c29b31cd-f2b2-41b6-86ee-9c78470abf01"
|
||||
```
|
||||
|
||||
Add audit, outbox, diagnostics, and redaction behavior for registration and
|
||||
factor lifecycle transitions.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- A caller can start and complete a headless registration flow from verified
|
||||
factor evidence.
|
||||
- Completed registration creates or resolves a stable NetKingdom user/account
|
||||
and external identity links.
|
||||
- Factor evidence is inspectable through safe metadata and evidence references,
|
||||
not raw proofing secrets.
|
||||
- Registration failure, expiry, and abandon states are auditable.
|
||||
- No credential, token, or proofing provider ownership moves into user-engine.
|
||||
|
||||
## Expected Outputs
|
||||
|
||||
- Registration and factor domain models.
|
||||
- Registration service facade.
|
||||
- Factor verification adapter ports.
|
||||
- Documentation and tests for the basic self-registration flow.
|
||||
@@ -0,0 +1,124 @@
|
||||
---
|
||||
id: USER-WP-0011
|
||||
type: workplan
|
||||
title: "Prepared Accounts And Entitlement Claims"
|
||||
domain: netkingdom
|
||||
repo: user-engine
|
||||
status: proposed
|
||||
owner: codex
|
||||
topic_slug: netkingdom
|
||||
planning_priority: high
|
||||
planning_order: 11
|
||||
created: "2026-06-15"
|
||||
updated: "2026-06-15"
|
||||
depends_on:
|
||||
- USER-WP-0010
|
||||
state_hub_workstream_id: "39ac9f87-c61d-42d8-a45f-bece4848ed47"
|
||||
---
|
||||
|
||||
# USER-WP-0011 - Prepared Accounts And Entitlement Claims
|
||||
|
||||
## Goal
|
||||
|
||||
Allow NetKingdom operators, tenant admins, family owners, service owners, or
|
||||
upstream systems to prepare account intent and access packages before the user
|
||||
registers. When the user later proves matching factors, user-engine can attach
|
||||
the prepared package to the canonical user and activate the right lifecycle
|
||||
steps.
|
||||
|
||||
## Scope Direction
|
||||
|
||||
Prepared accounts are not credentials. They are pending user-domain facts:
|
||||
expected factor matches, tenant or group references, planned memberships,
|
||||
profile defaults, onboarding journey hints, approval gates, expiry, and audit
|
||||
history.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Do not create login credentials for users who have not registered.
|
||||
- Do not bypass factor verification or approval policies.
|
||||
- Do not make user-engine the source of truth for external organization, HR, or
|
||||
directory records.
|
||||
- Do not implement final authorization policy decisions.
|
||||
|
||||
## Tasks
|
||||
|
||||
```task
|
||||
id: USER-WP-0011-T1
|
||||
status: todo
|
||||
priority: high
|
||||
state_hub_task_id: "11508f77-170b-4b22-bfdc-115a69bfe4db"
|
||||
```
|
||||
|
||||
Add prepared account and prepared entitlement models with status, expiry,
|
||||
preparer identity, tenant/scope references, factor match requirements, and
|
||||
audit metadata.
|
||||
|
||||
```task
|
||||
id: USER-WP-0011-T2
|
||||
status: todo
|
||||
priority: high
|
||||
state_hub_task_id: "86ca36d4-721b-48fe-8c0c-c6a1e6740d2f"
|
||||
```
|
||||
|
||||
Implement create, update, revoke, expire, and list operations for prepared
|
||||
accounts, guarded by the authorization port.
|
||||
|
||||
```task
|
||||
id: USER-WP-0011-T3
|
||||
status: todo
|
||||
priority: high
|
||||
state_hub_task_id: "fe5a08e8-1101-4cec-b02f-b2eee8928604"
|
||||
```
|
||||
|
||||
Implement claim matching during registration. Match verified factor evidence to
|
||||
prepared account requirements and produce explicit claim decisions.
|
||||
|
||||
```task
|
||||
id: USER-WP-0011-T4
|
||||
status: todo
|
||||
priority: high
|
||||
state_hub_task_id: "8aef6d9e-5e76-4e44-bf81-58049b22a25c"
|
||||
```
|
||||
|
||||
Convert claimed prepared entitlements into user-engine-owned facts:
|
||||
memberships, tenant accounts, profile defaults, application bindings, and
|
||||
onboarding journey starts.
|
||||
|
||||
```task
|
||||
id: USER-WP-0011-T5
|
||||
status: todo
|
||||
priority: medium
|
||||
state_hub_task_id: "527519a1-48ed-45fc-a6fc-739986ae6303"
|
||||
```
|
||||
|
||||
Add conflict and safety rules for duplicate prepared accounts, weak factor
|
||||
matches, expired packages, privileged roles, and manual approval requirements.
|
||||
|
||||
```task
|
||||
id: USER-WP-0011-T6
|
||||
status: todo
|
||||
priority: medium
|
||||
state_hub_task_id: "9530c8d6-82af-4635-8af8-aa79c54be94d"
|
||||
```
|
||||
|
||||
Add audit/outbox events and evidence references for preparation, claim,
|
||||
activation, denial, expiry, and revocation.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- A prepared account can be created before user registration without issuing
|
||||
credentials.
|
||||
- A registering user can claim prepared rights only when required factor
|
||||
evidence matches.
|
||||
- Claimed rights become explicit user-engine memberships, profile values,
|
||||
tenant account state, and onboarding events.
|
||||
- Expired, revoked, ambiguous, or privileged claims fail closed.
|
||||
- Every preparation and claim decision is auditable.
|
||||
|
||||
## Expected Outputs
|
||||
|
||||
- Prepared account domain model.
|
||||
- Prepared entitlement activation facade.
|
||||
- Claim matching rules and tests.
|
||||
- Documentation for account preparation boundaries.
|
||||
@@ -0,0 +1,118 @@
|
||||
---
|
||||
id: USER-WP-0012
|
||||
type: workplan
|
||||
title: "Hats, Realms, Services, Assets, And Access Profiles"
|
||||
domain: netkingdom
|
||||
repo: user-engine
|
||||
status: proposed
|
||||
owner: codex
|
||||
topic_slug: netkingdom
|
||||
planning_priority: high
|
||||
planning_order: 12
|
||||
created: "2026-06-15"
|
||||
updated: "2026-06-15"
|
||||
depends_on:
|
||||
- USER-WP-0010
|
||||
state_hub_workstream_id: "f3cf0d30-eb6b-4734-a0a3-5a755d4cf150"
|
||||
---
|
||||
|
||||
# USER-WP-0012 - Hats, Realms, Services, Assets, And Access Profiles
|
||||
|
||||
## Goal
|
||||
|
||||
Model how users and groups wear different hats across NetKingdom realms,
|
||||
services, and assets. Provide access-control facts, profile layers, and
|
||||
claims-enrichment context that authorization systems and service runtimes can
|
||||
consume without moving final policy decisions into user-engine.
|
||||
|
||||
## Scope Direction
|
||||
|
||||
user-engine owns the identity-domain representation of hats, memberships,
|
||||
access profiles, and active context. Authorization engines own policy decisions
|
||||
and protected services own runtime enforcement.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Do not implement the final ACL enforcement engine.
|
||||
- Do not define every service-specific permission in user-engine.
|
||||
- Do not bypass the authorization port.
|
||||
- Do not make browser/UI state the source of truth for active access context.
|
||||
|
||||
## Tasks
|
||||
|
||||
```task
|
||||
id: USER-WP-0012-T1
|
||||
status: todo
|
||||
priority: high
|
||||
state_hub_task_id: "b86f0072-e666-479b-9b90-96d4015bbfa0"
|
||||
```
|
||||
|
||||
Define realm, service area, asset scope, access profile, group, and hat
|
||||
vocabulary. Map each concept to current user-engine membership, profile, and
|
||||
canon reference patterns.
|
||||
|
||||
```task
|
||||
id: USER-WP-0012-T2
|
||||
status: todo
|
||||
priority: high
|
||||
state_hub_task_id: "66117083-8e85-44e1-9a76-cfd10dd24d23"
|
||||
```
|
||||
|
||||
Add hat selection and active context models. A user should be able to choose an
|
||||
active hat for a tenant, realm, service, or asset context when allowed.
|
||||
|
||||
```task
|
||||
id: USER-WP-0012-T3
|
||||
status: todo
|
||||
priority: high
|
||||
state_hub_task_id: "1dffda4c-f979-480e-9d6d-12ec9576780d"
|
||||
```
|
||||
|
||||
Implement access profile templates that combine memberships, factor assurance
|
||||
requirements, profile defaults, and claims projection rules.
|
||||
|
||||
```task
|
||||
id: USER-WP-0012-T4
|
||||
status: todo
|
||||
priority: high
|
||||
state_hub_task_id: "b07494fe-f301-49e2-8ea8-267a4c5219ee"
|
||||
```
|
||||
|
||||
Extend `identity_context` and claims-enrichment projections with active hat,
|
||||
realm, service, asset, group, access profile, and evidence references.
|
||||
|
||||
```task
|
||||
id: USER-WP-0012-T5
|
||||
status: todo
|
||||
priority: medium
|
||||
state_hub_task_id: "c78e10c4-b245-4a83-a75d-4b46a6073fd2"
|
||||
```
|
||||
|
||||
Add ports for exporting access-control facts to authorization engines or ACL
|
||||
systems while preserving source-of-truth boundaries.
|
||||
|
||||
```task
|
||||
id: USER-WP-0012-T6
|
||||
status: todo
|
||||
priority: medium
|
||||
state_hub_task_id: "f9f32165-3a12-424e-a370-bb2ab8348c21"
|
||||
```
|
||||
|
||||
Add tests for hat selection, cross-tenant denial, missing factor assurance,
|
||||
group-derived access, service-specific projection, and redacted diagnostics.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- Users can have multiple hats without collapsing them into one account state.
|
||||
- Active hat context is explicit in identity context and projections.
|
||||
- Access profile facts can be exported to authorization systems.
|
||||
- Missing tenant, realm, service, asset, factor, or approval context fails
|
||||
closed.
|
||||
- Final policy and ACL enforcement remain outside user-engine.
|
||||
|
||||
## Expected Outputs
|
||||
|
||||
- Hat and access profile domain model.
|
||||
- Active context service facade.
|
||||
- Identity-context and claims projection updates.
|
||||
- Access-control fact export tests.
|
||||
@@ -0,0 +1,107 @@
|
||||
---
|
||||
id: USER-WP-0013
|
||||
type: workplan
|
||||
title: "Onboarding Journeys And Welcome Protocols"
|
||||
domain: netkingdom
|
||||
repo: user-engine
|
||||
status: proposed
|
||||
owner: codex
|
||||
topic_slug: netkingdom
|
||||
planning_priority: medium
|
||||
planning_order: 13
|
||||
created: "2026-06-15"
|
||||
updated: "2026-06-15"
|
||||
depends_on:
|
||||
- USER-WP-0011
|
||||
- USER-WP-0012
|
||||
state_hub_workstream_id: "1dc82dfd-be68-4585-b6c9-6d24aebd3e27"
|
||||
---
|
||||
|
||||
# USER-WP-0013 - Onboarding Journeys And Welcome Protocols
|
||||
|
||||
## Goal
|
||||
|
||||
Create a journey layer that helps newly registered or newly entitled users
|
||||
enter the right NetKingdom subsystems. Welcome protocols should be driven by
|
||||
registration, prepared-account, invitation, role, profile, and access events.
|
||||
|
||||
## Scope Direction
|
||||
|
||||
user-engine owns journey state, task references, event correlation, and user
|
||||
context. Delivery systems, protected services, help content, notification
|
||||
channels, and external task systems remain adapters or downstream systems.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Do not build a notification platform.
|
||||
- Do not embed service-specific tours or support content in core domain code.
|
||||
- Do not replace external workflow/task systems.
|
||||
- Do not build the UI in this workplan.
|
||||
|
||||
## Tasks
|
||||
|
||||
```task
|
||||
id: USER-WP-0013-T1
|
||||
status: todo
|
||||
priority: high
|
||||
state_hub_task_id: "30ef8507-eebc-4b96-8aa6-c530bef05739"
|
||||
```
|
||||
|
||||
Define onboarding journey, welcome protocol, journey step, task, and subsystem
|
||||
handoff models.
|
||||
|
||||
```task
|
||||
id: USER-WP-0013-T2
|
||||
status: todo
|
||||
priority: high
|
||||
state_hub_task_id: "7c6e53d4-ff96-4036-a413-f04b4b73d266"
|
||||
```
|
||||
|
||||
Add journey templates keyed by registration outcome, prepared entitlement,
|
||||
tenant, realm, service, application, role, hat, and factor requirements.
|
||||
|
||||
```task
|
||||
id: USER-WP-0013-T3
|
||||
status: todo
|
||||
priority: high
|
||||
state_hub_task_id: "d9c2983a-45d1-4b1b-a416-63e180ca74b3"
|
||||
```
|
||||
|
||||
Implement journey start, progress, complete, skip, fail, and resume operations
|
||||
with authorization, audit, and outbox behavior.
|
||||
|
||||
```task
|
||||
id: USER-WP-0013-T4
|
||||
status: todo
|
||||
priority: medium
|
||||
state_hub_task_id: "7155c2eb-4e32-46f0-ad33-961784cb9a03"
|
||||
```
|
||||
|
||||
Add adapter ports for notifications, task systems, support content, subsystem
|
||||
welcome callbacks, and lifecycle task linking.
|
||||
|
||||
```task
|
||||
id: USER-WP-0013-T5
|
||||
status: todo
|
||||
priority: medium
|
||||
state_hub_task_id: "c5e42dd6-207a-4b1e-a0d8-35701e9f71bc"
|
||||
```
|
||||
|
||||
Expose onboarding status through identity context, diagnostics, and optional UI
|
||||
contracts.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- Registration or prepared-account claim can start an onboarding journey.
|
||||
- Journey state is resumable, auditable, and correlated with outbox events.
|
||||
- Subsystem welcome steps are adapter-driven, not hard-coded into core
|
||||
registration logic.
|
||||
- Users and admins can inspect pending onboarding work and blocked steps.
|
||||
- Missing subsystem callbacks produce explicit lifecycle gaps.
|
||||
|
||||
## Expected Outputs
|
||||
|
||||
- Onboarding journey domain model.
|
||||
- Welcome protocol service facade.
|
||||
- Adapter ports for notifications and subsystem handoff.
|
||||
- Scenario tests for successful, blocked, and resumed onboarding.
|
||||
125
workplans/USER-WP-0014-registration-and-access-management-ui.md
Normal file
125
workplans/USER-WP-0014-registration-and-access-management-ui.md
Normal file
@@ -0,0 +1,125 @@
|
||||
---
|
||||
id: USER-WP-0014
|
||||
type: workplan
|
||||
title: "Registration And Access Management UI"
|
||||
domain: netkingdom
|
||||
repo: user-engine
|
||||
status: proposed
|
||||
owner: codex
|
||||
topic_slug: netkingdom
|
||||
planning_priority: medium
|
||||
planning_order: 14
|
||||
created: "2026-06-15"
|
||||
updated: "2026-06-15"
|
||||
depends_on:
|
||||
- USER-WP-0010
|
||||
- USER-WP-0011
|
||||
- USER-WP-0012
|
||||
- USER-WP-0013
|
||||
state_hub_workstream_id: "011f7d20-5c9d-42a9-b7a3-b20a8ae9f557"
|
||||
---
|
||||
|
||||
# USER-WP-0014 - Registration And Access Management UI
|
||||
|
||||
## Goal
|
||||
|
||||
Build an optional NetKingdom registration and access management UI backed by
|
||||
user-engine APIs. The UI should make registration, factor status, prepared
|
||||
rights, hat selection, profile completion, and onboarding journeys convenient
|
||||
without hiding IAM, authorization, proofing, or service-runtime boundaries.
|
||||
|
||||
## Scope Direction
|
||||
|
||||
The UI is an operating surface over user-engine domain APIs. It should be thin,
|
||||
workflow-oriented, and suitable for self-service users, tenant admins, family
|
||||
owners, and operators.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Do not implement credential entry, password reset, passkeys, MFA challenges,
|
||||
or token issuance in the UI.
|
||||
- Do not embed final authorization policy rules in frontend code.
|
||||
- Do not replace service-specific admin consoles.
|
||||
- Do not make UI state authoritative over domain records.
|
||||
|
||||
## Tasks
|
||||
|
||||
```task
|
||||
id: USER-WP-0014-T1
|
||||
status: todo
|
||||
priority: high
|
||||
state_hub_task_id: "983087e1-c512-419f-86a6-b954d0a1ab54"
|
||||
```
|
||||
|
||||
Define UI information architecture for registration, factor status,
|
||||
prepared-account claim, hat selection, profile completion, onboarding journey,
|
||||
and admin setup views.
|
||||
|
||||
```task
|
||||
id: USER-WP-0014-T2
|
||||
status: todo
|
||||
priority: high
|
||||
state_hub_task_id: "0af5d8ef-0d1e-44bd-b807-bc40e87afef2"
|
||||
```
|
||||
|
||||
Define UI API contracts or route handlers over the headless service facades.
|
||||
Keep proofing, IAM, authorization, and notification calls behind adapters.
|
||||
|
||||
```task
|
||||
id: USER-WP-0014-T3
|
||||
status: todo
|
||||
priority: high
|
||||
state_hub_task_id: "a2e00aa3-5849-469c-a3a3-f4f5bd2df6c8"
|
||||
```
|
||||
|
||||
Implement the self-service registration flow with resume, prepared rights
|
||||
review, factor status, terms/consent, and completion states.
|
||||
|
||||
```task
|
||||
id: USER-WP-0014-T4
|
||||
status: todo
|
||||
priority: medium
|
||||
state_hub_task_id: "36d49049-cfe7-4f87-9a7f-78e37de9188a"
|
||||
```
|
||||
|
||||
Implement hat selection and active access context views for realms, services,
|
||||
groups, and assets.
|
||||
|
||||
```task
|
||||
id: USER-WP-0014-T5
|
||||
status: todo
|
||||
priority: medium
|
||||
state_hub_task_id: "e58038fc-6138-40cc-bb6b-4cbf7a8b0b87"
|
||||
```
|
||||
|
||||
Implement admin views for prepared accounts, invitations, access profiles,
|
||||
group membership, realms/services/assets, and onboarding diagnostics.
|
||||
|
||||
```task
|
||||
id: USER-WP-0014-T6
|
||||
status: todo
|
||||
priority: medium
|
||||
state_hub_task_id: "4de949d6-e330-41b2-87cf-9b9425f0f8be"
|
||||
```
|
||||
|
||||
Add usability, accessibility, error-state, redaction, and mobile/desktop tests
|
||||
for the registration and admin flows.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- A new user can complete a registration flow through the UI using adapter
|
||||
supplied factor evidence.
|
||||
- A prepared account claim can be reviewed and accepted or denied through the
|
||||
UI.
|
||||
- Users can choose an active hat and see available realms/services without
|
||||
exposing internal policy logic.
|
||||
- Admins can prepare accounts and inspect onboarding state.
|
||||
- The UI does not store or display secrets, raw proofing payloads, or hidden
|
||||
authorization decisions.
|
||||
|
||||
## Expected Outputs
|
||||
|
||||
- Registration UI and API contract.
|
||||
- Hat/access management UI views.
|
||||
- Admin prepared-account and onboarding views.
|
||||
- Frontend verification artifacts.
|
||||
@@ -0,0 +1,121 @@
|
||||
---
|
||||
id: USER-WP-0015
|
||||
type: workplan
|
||||
title: "Registration Scenario And Security Conformance"
|
||||
domain: netkingdom
|
||||
repo: user-engine
|
||||
status: proposed
|
||||
owner: codex
|
||||
topic_slug: netkingdom
|
||||
planning_priority: medium
|
||||
planning_order: 15
|
||||
created: "2026-06-15"
|
||||
updated: "2026-06-15"
|
||||
depends_on:
|
||||
- USER-WP-0010
|
||||
- USER-WP-0011
|
||||
- USER-WP-0012
|
||||
- USER-WP-0013
|
||||
- USER-WP-0014
|
||||
state_hub_workstream_id: "4f21e1c9-ad27-4ac9-888f-8f78c6abfb3b"
|
||||
---
|
||||
|
||||
# USER-WP-0015 - Registration Scenario And Security Conformance
|
||||
|
||||
## Goal
|
||||
|
||||
Prove the full NetKingdom registration and onboarding model through executable
|
||||
scenarios, security negative paths, redaction checks, adapter conformance, and
|
||||
operability diagnostics.
|
||||
|
||||
## Scope Direction
|
||||
|
||||
This workplan turns the registration roadmap into a testable contract. It
|
||||
should cover both headless APIs and the optional UI surface where present.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Do not add new product surface unless a test exposes a missing contract.
|
||||
- Do not assert provider-specific IAM, eID, SMS, email, or authorization engine
|
||||
internals.
|
||||
- Do not require production infrastructure for local conformance tests.
|
||||
|
||||
## Tasks
|
||||
|
||||
```task
|
||||
id: USER-WP-0015-T1
|
||||
status: todo
|
||||
priority: high
|
||||
state_hub_task_id: "5ca0a269-559d-4138-b702-9984a411f2ed"
|
||||
```
|
||||
|
||||
Define the registration scenario matrix: self-registration, prepared account
|
||||
claim, privileged role requiring approval, eID-backed assurance, family invite,
|
||||
tenant admin invite, group access, and denied cross-tenant claim.
|
||||
|
||||
```task
|
||||
id: USER-WP-0015-T2
|
||||
status: todo
|
||||
priority: high
|
||||
state_hub_task_id: "6ee492b1-923f-4aa0-8e17-b69f522c4898"
|
||||
```
|
||||
|
||||
Add end-to-end headless tests covering registration through identity context,
|
||||
claims enrichment, active hat selection, and onboarding event emission.
|
||||
|
||||
```task
|
||||
id: USER-WP-0015-T3
|
||||
status: todo
|
||||
priority: high
|
||||
state_hub_task_id: "b813a88f-ced6-40ce-9a25-d1c666fb73c9"
|
||||
```
|
||||
|
||||
Add security negative tests for weak factor evidence, duplicate identity links,
|
||||
prepared-account hijack attempts, expired claims, missing tenant context,
|
||||
privileged role escalation, and stale approvals.
|
||||
|
||||
```task
|
||||
id: USER-WP-0015-T4
|
||||
status: todo
|
||||
priority: medium
|
||||
state_hub_task_id: "5a03ac1a-1f8e-455b-8f75-691e8bdda286"
|
||||
```
|
||||
|
||||
Add redaction and diagnostics tests for factor values, profile sensitivity,
|
||||
prepared-account metadata, active hat context, and access-profile evidence.
|
||||
|
||||
```task
|
||||
id: USER-WP-0015-T5
|
||||
status: todo
|
||||
priority: medium
|
||||
state_hub_task_id: "fcf32b4d-d050-4989-bb05-844e0d13e548"
|
||||
```
|
||||
|
||||
Add adapter conformance tests for factor verification, authorization checks,
|
||||
access fact export, onboarding handoff, audit export, outbox replay, and
|
||||
durable store behavior.
|
||||
|
||||
```task
|
||||
id: USER-WP-0015-T6
|
||||
status: todo
|
||||
priority: medium
|
||||
state_hub_task_id: "a7850784-3b86-453f-bbc7-1d53d0813f82"
|
||||
```
|
||||
|
||||
Add UI flow tests once USER-WP-0014 exists: registration happy path, resume,
|
||||
prepared rights review, hat selection, admin preparation, and blocked journey.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- The main registration and onboarding journeys are executable as tests.
|
||||
- Security negative paths fail closed and leave audit evidence.
|
||||
- Sensitive factor and profile data is redacted from diagnostics and UI output.
|
||||
- Adapter contracts are testable without production infrastructure.
|
||||
- The registration UI, if implemented, is covered by workflow-level tests.
|
||||
|
||||
## Expected Outputs
|
||||
|
||||
- Registration scenario matrix.
|
||||
- Headless and UI conformance tests.
|
||||
- Security negative-path test suite.
|
||||
- Adapter conformance harness for registration dependencies.
|
||||
Reference in New Issue
Block a user