generated from coulomb/repo-seed
143 lines
5.0 KiB
Markdown
143 lines
5.0 KiB
Markdown
---
|
|
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
|
|
state_hub_workstream_id: "b5c85993-4aa2-4a8d-98b6-d174ab1b4538"
|
|
---
|
|
|
|
# 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
|
|
state_hub_task_id: "64c578e1-e2a1-48d4-8da9-659d4f881ef3"
|
|
```
|
|
|
|
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
|
|
state_hub_task_id: "19cfd23e-8a87-416d-b948-c727e8c5a11c"
|
|
```
|
|
|
|
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
|
|
state_hub_task_id: "d3b388de-bb79-41d5-805e-d2def88ac926"
|
|
```
|
|
|
|
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
|
|
state_hub_task_id: "d0e05af7-d777-4948-b072-79f1ffb9fc3a"
|
|
```
|
|
|
|
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
|
|
state_hub_task_id: "3c428960-be5b-411e-bd9b-7cba833abba8"
|
|
```
|
|
|
|
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
|
|
state_hub_task_id: "d606094a-254c-46d5-9bb8-a3449ce61c2c"
|
|
```
|
|
|
|
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.
|