Add Postgres durable store requirements

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

@@ -0,0 +1,135 @@
+---
+id: USER-WP-0009
+type: workplan
+title: "Postgres Durable Store Consumer Requirements"
+domain: netkingdom
+repo: user-engine
+status: proposed
+owner: codex
+topic_slug: netkingdom
+planning_priority: high
+planning_order: 9
+created: "2026-06-05"
+updated: "2026-06-05"
+depends_on:
+  - 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
+
+```task
+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.
+
+```task
+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.
+
+```task
+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.
+
+```task
+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.
+
+```task
+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.
+
+```task
+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.