user-engine/workplans/USER-WP-0009-postgres-durable-store-requirements.md

id, type, title, domain, repo, status, owner, topic_slug, planning_priority, planning_order, created, updated, depends_on

id	type	title	domain	repo	status	owner	topic_slug	planning_priority	planning_order	created	updated	depends_on
USER-WP-0009	workplan	Postgres Durable Store Consumer Requirements	netkingdom	user-engine	proposed	codex	netkingdom	high	9	2026-06-05	2026-06-05	USER-WP-0007

USER-WP-0009 - Postgres Durable Store Consumer Requirements

Goal

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.

Scope Direction

user-engine should be able to consume a NetKingdom-provided, tenant-aware, security-integrated Postgres capability through an adapter boundary. The future Postgres/provider repository should own provisioning, credentials, network policy, tenant isolation primitives, backup/restore, platform observability, and operational security. user-engine should own its domain schema, migrations for its own tables, store semantics, and conformance tests.

Non-Goals

• Do not implement a Postgres store adapter in this workplan.
• Do not add database dependencies to the package in this workplan.
• Do not provision Postgres, schemas, roles, credentials, certificates, or network access from this repository.
• Do not decide the final independent infrastructure repository layout.
• Do not move audit-platform, IAM, secrets, or authorization ownership into user-engine.
• Do not change the public service surface unless the requirements reveal a missing durable-store contract.

Tasks

id: USER-WP-0009-T1
status: todo
priority: high

Inventory the current in-memory store behavior and document the durable persistence semantics user-engine consumers already rely on: users, accounts, tenant accounts, external identities, applications, bindings, catalogs, profile values, memberships, audit records, outbox events, readiness, and schema version reporting.

id: USER-WP-0009-T2
status: todo
priority: high

Create a consumer-facing requirements document for a Postgres durable store. Cover connection handoff, tenant context, schema ownership, migrations, transactions, isolation, constraints, query behavior, audit/outbox durability, security, observability, backup/restore expectations, and acceptance tests.

id: USER-WP-0009-T3
status: todo
priority: high

Define the boundary between user-engine and the future NetKingdom Postgres provider repository. Specify which responsibilities belong to the provider, which belong to the user-engine adapter, and which must remain external IAM, secrets, authorization, or audit-platform concerns.

id: USER-WP-0009-T4
status: todo
priority: medium

Identify required changes, if any, to the existing store protocol or migration contract so durable implementations can satisfy the same service behavior as the isolated MVP without leaking Postgres concepts into domain code.

id: USER-WP-0009-T5
status: todo
priority: medium

Define conformance scenarios and failure-mode tests the future Postgres store must pass. Include transaction rollback, duplicate identity prevention, tenant-boundary enforcement, outbox exactly-once handoff semantics, migration readiness, and redacted diagnostics.

id: USER-WP-0009-T6
status: todo
priority: medium

Record open questions for the independent provider repository, including tenant isolation model, credential lease model, schema-per-service or database-per-tenant strategy, migration runner ownership, backup unit, PITR expectations, encryption, and operational runbooks.

Acceptance Criteria

• docs/postgres-durable-store-consumer-requirements.md exists and is clear enough for an independent NetKingdom Postgres provider repo to implement against.
• The document describes user-engine as a consumer of a secure Postgres capability, not as the owner of Postgres provisioning or platform security.
• Requirements cover domain persistence, transactions, migrations, tenant isolation, security, audit/outbox durability, operability, and acceptance tests.
• The provider-repo boundary is explicit and avoids duplicating IAM, secrets, authorization, audit-platform, or infrastructure ownership.
• 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.
• Follow-up implementation workplan inputs for a Postgres adapter.