coulomb/user-engine
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add implementation workplans and integration boundaries

Browse Source
This commit is contained in:
Bernd Worsch
2026-05-22 19:50:04 +02:00
parent fd088751ff
commit 1cd15cf79f
9 changed files with 791 additions and 34 deletions
Download Patch File Download Diff File Expand all files Collapse all files

89
INTENT.md
View File

@@ -1,63 +1,84 @@
# User Engine INTENT.md
# INTENT
> This file captures why this repository exists, the direction it is moving
> toward, and the kind of system it is meant to become. It is intentionally
> aspirational and stable, not a description of current implementation.
## Purpose
`user-engine` exists to provide a reusable, headless user domain service for applications, platforms, and repositories that need account, profile, preference, membership, and application-specific user attribute management without becoming tightly coupled to a single identity provider or UI.
`user-engine` exists to provide a reusable, headless user-domain service for
products and platforms that need account, profile, preference, membership, and
application-specific user attribute management without coupling those concerns
to a particular identity provider, authorization engine, or user interface.
## Primary Utility
The project provides a canonical user layer that can be embedded in small standalone services and extended into multi-tenant, multi-application, and multi-team environments.
The project provides a canonical user layer that can start small in a
standalone service and grow into governed multi-tenant, multi-application, and
multi-team environments.
It manages:
- users and account state
- external identity links
- profile and preference data
- tenant, application, and team memberships
- application-registered customization attributes
- catalog-driven profile schemas
- profile projections for consuming applications
- lifecycle and profile-change events
- users and account state;
- external identity links;
- profile and preference data;
- tenant, application, and team memberships;
- application-registered customization attributes;
- catalog-driven profile schemas;
- profile projections for consuming applications;
- lifecycle and profile-change events.
## Strategic Role
`user-engine` separates user-domain management from authentication, authorization, and application-specific UI concerns.
`user-engine` separates user-domain management from authentication,
authorization, credential lifecycle, and UI experience concerns.
It is intended to integrate with established identity and access systems such as OIDC providers, SCIM provisioning sources, LDAP-compatible directories, and external authorization engines, while remaining useful in simple standalone deployments.
It is intended to integrate through standards-aligned interfaces with identity
providers, provisioning sources, directories, authorization systems, event
sinks, and optional UI surfaces while remaining useful in simple standalone
deployments.
## Intended Users
- application developers adding user/account functionality to a service
- platform teams managing users across multiple applications
- product teams needing self-service account and preference management
- operators and tenant administrators managing scoped user populations
- agentic systems that need structured access to user preferences and profile context
- application developers adding user/account functionality to a service;
- platform teams managing users across multiple applications;
- product teams needing self-service account and preference capabilities;
- operators and tenant administrators managing scoped user populations;
- agentic systems that need structured access to user preferences and profile
context.
## Product Boundaries
`user-engine` is the headless backend and domain service.
Related UI surfaces may be provided separately:
It does not aim to be:
- `user-account` for self-service account, profile, and preference management by the individual user
- `user-manager` for administrative and operational management of users in a tenant, application, team, or platform scope
- a full identity provider;
- a password, passkey, session, or MFA system;
- a fine-grained authorization engine;
- a directory server;
- a UI application.
`user-engine` does not aim to be a full identity provider, password/MFA system, or fine-grained authorization engine, though it may integrate with such systems.
It provides the user-domain APIs, catalog metadata, projections, events, and
audit records that those surrounding systems can consume.
## Design Principles
- headless first
- optional UI, not UI-driven
- standalone-friendly
- enterprise-integratable
- identity-provider agnostic
- authorization-engine agnostic
- catalog-driven customization
- explicit ownership, visibility, mutability, and sensitivity of attributes
- layered profiles instead of one global metadata blob
- concrete user-domain focus with a possible future extraction path toward a generic profile engine
- headless first;
- optional UI, not UI-driven;
- standalone-friendly;
- enterprise-integratable;
- identity-provider agnostic;
- authorization-engine agnostic;
- catalog-driven customization;
- explicit ownership, visibility, mutability, and sensitivity of attributes;
- layered profiles instead of one global metadata blob;
- deterministic and inspectable effective profile resolution;
- concrete user-domain focus with a possible future extraction path toward a
generic profile engine.
## Success Definition
`user-engine` succeeds when a repository or application can add robust user-domain capabilities with minimal coupling, while still having a clear path from a simple local setup to a governed multi-tenant, multi-application deployment.
`user-engine` succeeds when a repository or application can add robust
user-domain capabilities with minimal coupling while keeping a clear path from
a simple local setup to a governed multi-tenant, multi-application deployment.

47
SCOPE.md Normal file
View File

@@ -0,0 +1,47 @@
# SCOPE
## One-Liner
Headless user-domain and profile engine for accounts, identity links,
preferences, memberships, application catalogs, projections, audit, and
events.
## In Scope
- user and account records;
- account lifecycle state;
- external identity links;
- global, tenant, application, and membership profile values;
- preference values;
- tenant, application, team, and scope memberships;
- application registry for profile consumers;
- customization catalog registry and validation;
- effective profile resolution;
- projection APIs for self-service, admin, application runtime, audit, and
agent contexts;
- audit records and lifecycle/profile-change events;
- local standalone development mode;
- integration ports for identity claims, authorization checks, events, and
runtime secrets.
## Out Of Scope
- login and authentication flows;
- password, passkey, session, and MFA lifecycle;
- OIDC/SAML token issuance;
- final authorization policy decisions;
- runtime secret custody;
- UI implementation;
- full SCIM server or enterprise directory replacement in the initial product.
## Boundary Rule
user-engine owns user-domain facts and projections. Other systems may provide
identity, authorization, deployment, event transport, or UI surfaces, but they
must integrate through explicit interfaces rather than becoming hidden sources
of profile truth.
## Current Planning
Implementation work is tracked in `workplans/USER-WP-0001` through
`USER-WP-0006`.

82
docs/interfaces/netkingdom-integration.md Normal file
View File

@@ -0,0 +1,82 @@
# NetKingdom Integration Interfaces
Status: initial implementation guidance
Date: 2026-05-22
## Purpose
This document translates the NetKingdom user-engine interface guidance into
repo-local implementation boundaries. It is intentionally practical: these are
the ports, adapters, and data contracts the implementation should preserve.
## Required Ports
| Port | Direction | Purpose |
| --- | --- | --- |
| `IdentityClaimsAdapter` | inbound | Accept a verified identity envelope and map `(issuer, subject)` to a local `user_id`. |
| `AuthorizationCheckPort` | outbound | Ask an authorization service whether an actor may perform a user-engine action. |
| `ApplicationBindingStore` | local | Bind a user-engine application to external OIDC clients, protected systems, catalog namespaces, and event identities. |
| `MembershipFactExporter` | outbound | Export user-engine-owned membership facts as read models for authorization systems. |
| `EventOutbox` | outbound | Publish durable lifecycle/profile/catalog/membership events after commit. |
| `AuditWriter` | local/outbound | Persist local audit and provide redacted summaries for platform audit sinks. |
| `SecretProvider` | inbound | Load runtime secrets through environment/local config in standalone mode and scoped secret providers in platform mode. |
## Source-Of-Truth Rules
- user-engine is the source of truth for user records, account lifecycle,
identity links, profile values, preferences, memberships it creates, catalog
definitions, and projections.
- Identity providers are the source of truth for authentication-time subject,
issuer, assurance, coarse role, and group claims.
- Authorization systems decide whether an actor may perform an action.
- Event sinks and audit stores consume user-engine events; they do not become
profile stores.
## Authorization Request Shape
Every protected operation should be reducible to:
```yaml
actor:
issuer: string
subject: string
tenant: string
principal_type: human | service | agent
roles: [string]
groups: [string]
scopes: [string]
assurance: object
resource:
type: user-engine:user | user-engine:profile | user-engine:membership | user-engine:application | user-engine:catalog | user-engine:projection | user-engine:audit
id: string
action: string
context:
tenant: string
application_id: string | null
target_user_id: string | null
correlation_id: string
```
The domain layer should depend on this port, not on a concrete authorization
client.
## Projection Types
- `self_service`: current-user view and allowed mutations.
- `admin`: scope-admin view and allowed mutations.
- `application_runtime`: data a registered application may consume.
- `audit`: redacted operational trace.
- `agent_context`: policy-filtered context for agentic systems.
- `claims_enrichment`: optional adapter-owned input for identity systems.
user-engine must not issue tokens. Claims enrichment is optional and must be
cache/freshness governed by the identity-side adapter.
## Implementation Implications
- Keep domain logic independent of HTTP, database, and authorization clients.
- Validate catalog ownership before accepting attribute values.
- Resolve effective profiles deterministically and expose resolution metadata.
- Persist audit and outbox events in the same transaction as mutations.
- Use request-scoped memoization and batch authorization checks for list views.
- Fail closed for sensitive writes when authorization cannot be determined.

82
workplans/USER-WP-0001-preparation-and-interface-adoption.md Normal file
View File

@@ -0,0 +1,82 @@
---
id: USER-WP-0001
type: workplan
title: "User Engine Preparation And Interface Adoption"
domain: netkingdom
repo: user-engine
status: ready
owner: codex
topic_slug: netkingdom
planning_priority: high
planning_order: 1
created: "2026-05-22"
updated: "2026-05-22"
state_hub_workstream_id: "cc5ff9a5-5592-45e3-b7ef-cf6c7fab0f03"
---
# USER-WP-0001 - User Engine Preparation And Interface Adoption
## Goal
Prepare this repository for implementation by adopting the boundary guidance
from the PRD, architecture blueprint, and NetKingdom interface guidance.
## Tasks
```task
id: USER-WP-0001-T1
status: todo
priority: high
state_hub_task_id: "7f91d466-2f97-4acf-832a-e9de0b21be04"
```
Define the initial repository layout, implementation stack, local commands,
test commands, and module boundaries.
```task
id: USER-WP-0001-T2
status: todo
priority: high
state_hub_task_id: "940ce697-fbad-4ef9-9024-175f482b2d3a"
```
Implement or document the core ports: identity claims adapter, authorization
check port, application binding store, membership fact exporter, event outbox,
audit writer, and secret provider.
```task
id: USER-WP-0001-T3
status: todo
priority: high
state_hub_task_id: "c16bd102-0f86-4951-86ee-8d6088ac888b"
```
Create initial schemas for users, accounts, identity links, applications,
catalogs, profile values, memberships, audit records, and outbox events.
```task
id: USER-WP-0001-T4
status: todo
priority: medium
state_hub_task_id: "9e962947-6d1f-49ae-a362-d8a13d430b87"
```
Create local development fixtures for verified identity envelopes and
authorization decisions.
```task
id: USER-WP-0001-T5
status: todo
priority: medium
state_hub_task_id: "c5b24341-ae26-48a0-97ac-6fbcf108b0e0"
```
Document standalone and platform mode configuration boundaries.
## Acceptance Criteria
- The repo has a clear implementation layout and command set.
- Interface ports exist as code or precise specs.
- Domain ownership does not duplicate identity, authorization, secret custody,
deployment, or UI responsibilities.
- USER-WP-0002 can start without unresolved interface ownership.

103
workplans/USER-WP-0002-isolated-mvp.md Normal file
View File

@@ -0,0 +1,103 @@
---
id: USER-WP-0002
type: workplan
title: "User Engine Isolated MVP"
domain: netkingdom
repo: user-engine
status: ready
owner: codex
topic_slug: netkingdom
planning_priority: high
planning_order: 2
created: "2026-05-22"
updated: "2026-05-22"
depends_on:
- USER-WP-0001
state_hub_workstream_id: "780ce3bb-9af0-43dc-85cd-a9288e3d74c7"
---
# USER-WP-0002 - User Engine Isolated MVP
## Goal
Implement the smallest useful headless service in isolation: users, accounts,
identity links, one application, one catalog, profile values, effective
profile resolution, projections, audit, outbox, and tests.
## Tasks
```task
id: USER-WP-0002-T1
status: todo
priority: high
state_hub_task_id: "0b43c19e-7ca4-4d32-93f4-3c083a200092"
```
Implement the domain model and local persistence migrations.
```task
id: USER-WP-0002-T2
status: todo
priority: high
state_hub_task_id: "d6404f5c-292f-4eb5-819b-42fe8c237c60"
```
Implement IAM Profile-compatible fixture actor handling and local identity
linking by `(issuer, subject)`.
```task
id: USER-WP-0002-T3
status: todo
priority: high
state_hub_task_id: "b0b0ad70-d590-4faf-916e-41dbf25d6c5f"
```
Implement the authorization check port with a deterministic local test
adapter.
```task
id: USER-WP-0002-T4
status: todo
priority: high
state_hub_task_id: "ce310565-75e3-4fb4-9358-0aaff14a8ada"
```
Implement headless APIs for health, readiness, `me`, users, account lifecycle,
identity links, applications, catalogs, profiles, projections, and audit.
```task
id: USER-WP-0002-T5
status: todo
priority: high
state_hub_task_id: "4ebb8649-e3ff-4da8-80cd-eef8b1488129"
```
Implement catalog validation, profile value validation, defaults, global plus
application profile layers, and inspectable effective profile resolution.
```task
id: USER-WP-0002-T6
status: todo
priority: high
state_hub_task_id: "a238bbd8-95bb-499a-85f4-744acce188d4"
```
Persist audit records and outbox events atomically with mutations.
```task
id: USER-WP-0002-T7
status: todo
priority: high
state_hub_task_id: "a9826644-1fea-4ada-bc21-7c545e790ffc"
```
Add tests for lifecycle, identity linking, catalog validation, profile update
authorization, projections, redaction, audit/outbox atomicity, and deny paths.
## Acceptance Criteria
- A demo application can register, publish a catalog, write profile values,
and read an effective projection.
- Self-service and admin-style operations work through the local auth adapter.
- Sensitive values are redacted in non-eligible projections.
- MVP tests cover positive and negative use cases.

102
workplans/USER-WP-0003-multi-tenancy.md Normal file
View File

@@ -0,0 +1,102 @@
---
id: USER-WP-0003
type: workplan
title: "User Engine Multi-Tenancy"
domain: netkingdom
repo: user-engine
status: ready
owner: codex
topic_slug: netkingdom
planning_priority: high
planning_order: 3
created: "2026-05-22"
updated: "2026-05-22"
depends_on:
- USER-WP-0002
state_hub_workstream_id: "88a11922-7064-4373-9afe-b280bdd4359a"
---
# USER-WP-0003 - User Engine Multi-Tenancy
## Goal
Extend the MVP into a tenant-aware service with explicit platform-vs-tenant
boundaries, tenant profiles, tenant memberships, tenant-scoped admin actions,
and tenant isolation tests.
## Tasks
```task
id: USER-WP-0003-T1
status: todo
priority: high
state_hub_task_id: "3b6d67cc-be4d-4da3-b08c-f5919c1cb167"
```
Implement tenant identifiers, tenant context resolution, and request validation.
```task
id: USER-WP-0003-T2
status: todo
priority: high
state_hub_task_id: "9b8cb25a-eae5-4c6d-abdb-87fa73ba2cc6"
```
Add tenant-scoped account state, profile values, memberships, and persistence
constraints.
```task
id: USER-WP-0003-T3
status: todo
priority: high
state_hub_task_id: "a7abd6b0-c35a-4b3a-ae60-1d7db41398f8"
```
Implement tenant admin operations while denying platform-root operations to
tenant admins.
```task
id: USER-WP-0003-T4
status: todo
priority: high
state_hub_task_id: "9deb9f46-d214-4311-9b19-7f61d75b4aaa"
```
Extend authorization requests with tenant, target user, membership, assurance,
and scope facts.
```task
id: USER-WP-0003-T5
status: todo
priority: medium
state_hub_task_id: "ea8d4127-7ef1-4a7a-80fb-11c8f00c25c3"
```
Add tenant-aware audit records and outbox events.
```task
id: USER-WP-0003-T6
status: todo
priority: high
state_hub_task_id: "7d1071a2-c85f-4a21-9842-fcb826c0172d"
```
Add tests for cross-tenant denial, tenant admin allowed actions, tenant admin
platform-root denial, tenant profile precedence, and tenant membership changes.
```task
id: USER-WP-0003-T7
status: todo
priority: medium
state_hub_task_id: "6c9e6b82-9a8f-4017-96c3-5df9f3185154"
```
Add tenant onboarding diagnostics for memberships, policy bindings, catalog
scopes, and audit readiness.
## Acceptance Criteria
- Tenant context is explicit on every tenant-scoped operation.
- Tenant data is isolated by constraints and authorization.
- Tenant admins cannot modify platform-root resources.
- Tests cover allowed and denied tenant paths.

106
workplans/USER-WP-0004-multi-application-catalogs.md Normal file
View File

@@ -0,0 +1,106 @@
---
id: USER-WP-0004
type: workplan
title: "User Engine Multi-Application And Catalog Support"
domain: netkingdom
repo: user-engine
status: ready
owner: codex
topic_slug: netkingdom
planning_priority: high
planning_order: 4
created: "2026-05-22"
updated: "2026-05-22"
depends_on:
- USER-WP-0002
state_hub_workstream_id: "85676f7f-c82c-411a-9e1f-92098e8662ba"
---
# USER-WP-0004 - User Engine Multi-Application And Catalog Support
## Goal
Support multiple registered applications, catalog namespace ownership,
versioned customization catalogs, application-specific profile layers, and
runtime projections without attribute collisions or data leakage.
## Tasks
```task
id: USER-WP-0004-T1
status: todo
priority: high
state_hub_task_id: "a9952b07-35e0-4b6a-921e-321c55fee011"
```
Implement user-engine application records with bindings to external client,
protected-system, catalog namespace, event identity, and deployment metadata.
```task
id: USER-WP-0004-T2
status: todo
priority: high
state_hub_task_id: "d4ada2e3-9859-489c-b2a9-529b0d9e03fb"
```
Implement catalog namespace ownership, semantic versions, lifecycle states,
compatibility checks, and sensitivity downgrade prevention.
```task
id: USER-WP-0004-T3
status: todo
priority: high
state_hub_task_id: "add3cbdb-f7ec-4362-a257-93ab874a2093"
```
Add application-specific profile values, preferences, defaults, and precedence
rules.
```task
id: USER-WP-0004-T4
status: todo
priority: high
state_hub_task_id: "d5ef60ee-c007-4efd-86e4-3244e92c555a"
```
Implement application runtime projections with attribute-level visibility,
mutability, sensitivity, and redaction rules.
```task
id: USER-WP-0004-T5
status: todo
priority: medium
state_hub_task_id: "c824c44d-24f5-4f28-91fd-4d739b5fa254"
```
Specify and optionally prototype a cache-backed claims-enrichment projection
adapter that does not make user-engine a token issuer.
```task
id: USER-WP-0004-T6
status: todo
priority: high
state_hub_task_id: "8a506280-d8d6-4fbd-9d05-831a76e3e8be"
```
Add tests for namespace collisions, catalog activation failures,
application-specific profile values, projection redaction, application access
denial, and catalog migration checks.
```task
id: USER-WP-0004-T7
status: todo
priority: medium
state_hub_task_id: "c8fd8760-ccc4-4df4-85c7-c1c4950b82d9"
```
Add developer-facing examples for registering an application, publishing a
catalog, requesting projections, and handling profile-change events.
## Acceptance Criteria
- Multiple applications can register without attribute collisions.
- Catalog ownership and lifecycle are enforced.
- Application-specific values resolve consistently with global and tenant
layers.
- Claims enrichment remains optional and adapter-owned.

108
workplans/USER-WP-0005-integrated-test-scenarios.md Normal file
View File

@@ -0,0 +1,108 @@
---
id: USER-WP-0005
type: workplan
title: "User Engine Integrated Test Scenarios"
domain: netkingdom
repo: user-engine
status: ready
owner: codex
topic_slug: netkingdom
planning_priority: high
planning_order: 5
created: "2026-05-22"
updated: "2026-05-22"
depends_on:
- USER-WP-0003
- USER-WP-0004
state_hub_workstream_id: "06face5b-6984-4acc-8128-f82d61abdc75"
---
# USER-WP-0005 - User Engine Integrated Test Scenarios
## Goal
Prove the architecture boundaries with realistic standalone, platform,
multi-tenant, multi-application, projection, audit, event, and performance
test scenarios.
## Tasks
```task
id: USER-WP-0005-T1
status: todo
priority: high
state_hub_task_id: "f0408602-4ec9-4d01-9a62-2daa3fa7373e"
```
Define the canonical scenario matrix for standalone, denied access, tenant
admin, platform operator, cross-tenant denial, two applications, sensitive
redaction, and audit/event replay.
```task
id: USER-WP-0005-T2
status: todo
priority: high
state_hub_task_id: "78dad786-f69d-4e84-884b-0e2a32338c3e"
```
Add identity fixtures for human, service, agent, delegated agent, tenant
admin, platform operator, break-glass, local issuer, invalid, expired, and
missing-tenant actors.
```task
id: USER-WP-0005-T3
status: todo
priority: high
state_hub_task_id: "87cac8eb-2182-4b17-aa29-60109cf6f2c4"
```
Add an authorization harness for allow, deny, obligation, tenant-boundary,
assurance, and bulk decision scenarios.
```task
id: USER-WP-0005-T4
status: todo
priority: high
state_hub_task_id: "5fc6e120-0c94-4fb0-bc7f-2d8713a40011"
```
Test full flows from actor claims through authorization, mutation, profile
resolution, projection, audit write, and outbox event creation.
```task
id: USER-WP-0005-T5
status: todo
priority: medium
state_hub_task_id: "609a3579-268c-4ed9-b5b7-2e01dc8e7049"
```
Add tests or benchmarks for effective-profile resolution, projection
rendering, authorization batching, memoization, and cache invalidation.
```task
id: USER-WP-0005-T6
status: todo
priority: high
state_hub_task_id: "c346a142-3e7a-48ee-bf71-553cdcf4861d"
```
Add security and privacy negative tests for local issuer rejection, sensitive
leakage, cross-tenant access, admin overreach, catalog downgrade, namespace
hijack, stale membership facts, and missing audit correlation.
```task
id: USER-WP-0005-T7
status: todo
priority: medium
state_hub_task_id: "ac92965e-778d-48ec-a674-32b1c333bb0d"
```
Add CI/readiness commands for unit, integration, scenario, and
conformance-style test suites.
## Acceptance Criteria
- Scenario tests prove standalone, tenant, multi-app, authorization, profile,
projection, audit, and event behavior.
- Negative tests cover the architecture review risks.
- CI/readiness commands are documented and deterministic.

106
workplans/USER-WP-0006-finalization-polish.md Normal file
View File

@@ -0,0 +1,106 @@
---
id: USER-WP-0006
type: workplan
title: "User Engine Implementation Assessment And Polish"
domain: netkingdom
repo: user-engine
status: ready
owner: codex
topic_slug: netkingdom
planning_priority: medium
planning_order: 6
created: "2026-05-22"
updated: "2026-05-22"
depends_on:
- USER-WP-0005
state_hub_workstream_id: "8260c3ec-73cd-4c37-b15e-a856a01bbdfa"
---
# USER-WP-0006 - User Engine Implementation Assessment And Polish
## Goal
Assess the implementation against the PRD, architecture blueprint, interface
guidance, and integrated scenarios. Finalize public contracts, documentation,
operability, packaging, and UI handoff readiness.
## Tasks
```task
id: USER-WP-0006-T1
status: todo
priority: high
state_hub_task_id: "e0b5621a-4935-45a6-bbd0-41476b3d3317"
```
Review implemented behavior against the PRD, architecture blueprint, and
interface guidance. Record gaps, accepted deviations, and follow-up work.
```task
id: USER-WP-0006-T2
status: todo
priority: high
state_hub_task_id: "467eebf2-3a16-45b0-a5bd-28b5c1b634b1"
```
Verify user-engine has not absorbed identity provider, MFA, credential, PDP,
UI, or deployment responsibilities.
```task
id: USER-WP-0006-T3
status: todo
priority: medium
state_hub_task_id: "3b7efcaf-041d-4262-973d-6cfd2a011b47"
```
Stabilize endpoint names, error taxonomy, catalog schemas, projection
responses, audit event shapes, and migration contracts.
```task
id: USER-WP-0006-T4
status: todo
priority: medium
state_hub_task_id: "a0bc5469-6c6f-429a-a58e-2f6c6489f5c3"
```
Add readiness diagnostics, metrics, structured logs, audit correlation checks,
outbox drain diagnostics, cache status, and runbooks.
```task
id: USER-WP-0006-T5
status: todo
priority: medium
state_hub_task_id: "996ffd8d-5006-4393-8214-be8072ebae8e"
```
Finalize developer docs for standalone setup, application onboarding, catalog
authoring, projection consumption, tenant boundaries, and event/audit
integration.
```task
id: USER-WP-0006-T6
status: todo
priority: medium
state_hub_task_id: "bc1ca685-be53-4f70-8717-7d7226c81944"
```
Decide versioning, packaging, build artifacts, SBOM/security scan
requirements, migration policy, and compatibility guarantees.
```task
id: USER-WP-0006-T7
status: todo
priority: low
state_hub_task_id: "7c4fa8b5-f6c4-434a-85e6-0048449fbdc8"
```
Prepare backend contracts and fixtures needed by future self-service and admin
UI surfaces.
## Acceptance Criteria
- A final assessment records what was implemented, what changed, and what
remains open.
- Public API, schema, catalog, and projection contracts are coherent.
- Operability and release-readiness checks pass.
- Future UI work has a clear backend contract.