b3-prosaic-harness-postgres 0.4.0__tar.gz → 0.4.2__tar.gz

{b3_prosaic_harness_postgres-0.4.0/src/b3_prosaic_harness_postgres.egg-info → b3_prosaic_harness_postgres-0.4.2}/PKG-INFO

@@ -1,13 +1,13 @@
 Metadata-Version: 2.4
 Name: b3-prosaic-harness-postgres
-Version: 0.4.0
+Version: 0.4.2
 Summary: Explicit PostgreSQL run and conversation storage for Prosaic Harness
 License-Expression: Apache-2.0
 Requires-Python: >=3.11
 Description-Content-Type: text/markdown
 License-File: LICENSE
 License-File: NOTICE
-Requires-Dist: b3-prosaic-harness<0.10,>=0.9
+Requires-Dist: b3-prosaic-harness<0.10,>=0.9.13
 Requires-Dist: psycopg[binary]<4,>=3.2.3
 Requires-Dist: psycopg-pool<4,>=3.2
 Provides-Extra: test
@@ -20,28 +20,58 @@ Dynamic: license-file
 
 # PostgreSQL persistence for Prosaic Harness
 
+PostgreSQL adapter **0.4.2** requires Harness **0.9.13** or later
+in the compatible family. Explicit owner migration enables
+workflow storage contract2 or conversation contract3; readiness performs no DDL.
+See [context-pack migration and rollback](../../docs/context-packs.md#current-authorization-and-durable-storage).
+
+See [0.4.2 release and migration notes](../../docs/release-postgres-0.4.2.md)
+and [compatible SDK versions](https://github.com/B3Cognition/prosaic-harness/blob/main/docs/releases.md).
+
 Run on worker A, inspect/resume on worker B, without a shared writable run
 directory. Core remains database-free; install this separate adapter only when
 you need shared durable state. The API is synchronous; a private I/O thread
 bounds network waits. Model execution holds no database connection/transaction.
-The conversation candidate is `b3-prosaic-harness-postgres` **0.3.0**, selecting
-`b3-prosaic-harness>=0.8,<0.9`. The adapter is maintained in this repository but
-installed and versioned separately, keeping PostgreSQL drivers optional for
-Harness users. Imports and CLI names remain unchanged. Final qualification and
-publication of this conversation release train are pending. The historical
-[Harness v0.6.1 release](https://github.com/B3Cognition/prosaic-harness/releases/tag/v0.6.1)
-retains its original 0.6.1/0.1.1 package names and receipts.
+The adapter is independently versioned: `b3-prosaic-harness-postgres` **0.4.2**
+requires `b3-prosaic-harness>=0.9.13,<0.10`. PostgreSQL drivers remain optional for
+core Harness users. Imports and CLI names are unchanged.
+
+## Durability profiles
+
+The default `durability_profile="postgresql"` requires `full_page_writes=on`.
+An operator who has independently verified an Amazon Aurora PostgreSQL cluster
+may explicitly select `durability_profile="aurora-postgresql"` on both
+`PostgresRunStore` and `PostgresSessionStore` (including `from_env`). This accepts
+`full_page_writes=off` under Aurora's log-based storage contract. It does not
+weaken fsync, synchronous commit, writable-primary, logged-table, lease or
+unknown-commit checks. The guard runs for every operation and connection reuse.
+Invalid profiles fail before connecting. This profile is an operator assertion,
+not engine autodetection or proof that arbitrary storage is safe. NEVER select
+it for ordinary PostgreSQL just to suppress a readiness failure.
+
+For every CLI command, pass `--durability-profile aurora-postgresql` explicitly.
+Migration and runtime must select the same profile. Verify the actual engine and
+version with AWS RDS metadata/DBA evidence; AWS also documents `aurora_version()`.
+Capture a failed SQL probe's actual error and inspect its schema/search path;
+NEVER convert an unavailable probe into permission to bypass durability checks.
+No AWS credentials or model calls are needed by the adapter.
+
+AWS describes the storage contract in
+[its architecture guide](https://aws.amazon.com/blogs/database/is-amazon-rds-for-postgresql-or-amazon-aurora-postgresql-a-better-choice-for-me/).
+Native PostgreSQL tests qualify the policy and all existing recovery behavior;
+they do not emulate Aurora storage. An actual Aurora deployment needs synthetic
+persistence/restart/failover qualification before enabling production work.
 
 ## 1. Install and supply an existing database
 
 Python 3.11+, PostgreSQL 16 or 18 on a writable primary, and libpq 17+ are
 required. `psycopg[binary]` supplies libpq; older libpq is rejected.
-From the exact candidate Harness checkout, use a new environment and a curated
-wheelhouse containing only the manifest-selected b3 candidate wheels:
+Use a fresh environment and the published compatible SDKs:
 
 ```sh
 python3 -m venv .venv-postgres
-.venv-postgres/bin/python -m pip install --find-links /absolute/path/to/curated-wheelhouse . ./adapters/postgres
+.venv-postgres/bin/python -m pip install 'b3-prosaic-harness==0.9.11' \
+  'b3-prosaic-runtime==0.9.19' 'b3-prosaic-harness-postgres==0.4.2'
 export PATH="$PWD/.venv-postgres/bin:$PATH"
 prosaic --version
 prosaic-harness-postgres --help
@@ -49,8 +79,13 @@ prosaic-harness-postgres --help
 
 ALWAYS migrate using a fresh environment or image; NEVER install legacy and b3
 distributions together because they own the same import paths. See
-[package migration](../../docs/package-migration.md). The Runtime 0.9 candidate
-must be available before this installation can resolve.
+[package migration](../../docs/package-migration.md). For reproducible installs,
+verify the complete selected manifest's wheel hashes before installation.
+
+Agent reasoning effort is passed through Harness to Runtime; this store does
+not turn thinking on or prove provider compliance. Frozen prose/configuration
+and workflow identity still govern resume. See [reasoning effort](../../docs/reasoning-effort.md)
+and the Integration Lab's separate blueprint and control-check lane.
 
 Harness does **not** provision PostgreSQL, create databases/users, start a
 service, or fall back to files. Your operator supplies two DSNs through a secret
@@ -159,6 +194,10 @@ remain supported; the adapter adds no new workflow interpreter.
   budget 10s, pool/connect 5s, row lock 1s, statement 5s. Deadlines cover pool,
   network and COMMIT waits. Stalled connections are quarantined; unresolved
   operations retain capacity and prevent unsafe close.
+- Ordinary operations use the configured short lock timeout. Dedicated renewal
+  operations can wait for a same-owner write within the configured statement
+  and total operation deadlines. Failed renewal remains sticky; ownership and
+  generation checks still fence every write.
 - Default lazy pool bounds per store/process: 8 ordinary + 4 renewal connections,
   maximum 4 active leases. Renewal has reserved capacity. Multiply capacity
   across replicas/namespaces; do not create a pool per HTTP request. Applications
@@ -213,7 +252,7 @@ python adapters/postgres/tests/support/local_cluster.py stop --manifest "$FIXTUR
 Repeat with version 18. Stop validates exact IDs/names/ownership labels before
 removing only owned containers/volumes/network. Generated fixture networks and
 loopback ports use synthetic trust authentication, never production defaults.
-# Lease registration candidate
+# Lease registration
 
 The adapter transfers acquisition capacity into registered
 session capacity atomically under the existing store mutex. A registering lease
@@ -223,7 +262,7 @@ an owned PostgreSQL 16/18 race regression cover the transition.
 
 ## Optional conversation sessions
 
-The conversation candidate adds `PostgresSessionStore` to this same optional
+Conversation storage provides `PostgresSessionStore` to this same optional
 distribution. It implements the public Harness `SessionStore` contract and uses
 the independent, logged `prosaic_harness_conversations` schema, storage version 1.
 Existing `PostgresRunStore` tables, grants and CLI `init`/`doctor` behavior remain
@@ -315,7 +354,7 @@ The required adapter suite includes both the existing workflow backend and the
 conversation backend. Run the owned PostgreSQL 16 and 18 fixtures shown above
 with `--require-postgres`. Missing infrastructure or any skipped required case
 fails qualification. Installed Linux AMD64 and ARM64 acceptance is required
-before claiming the conversation candidate is ready for production.
+before treating a conversation deployment as ready for production.
 
 ## Optional context storage contract
 
@@ -335,3 +374,31 @@ cannot update schema metadata. Old workers reject the upgraded storage contract.
 Keep migration-owner credentials separate from runtime credentials. Enable host
 context policies only after Runtime, Harness and store advertise the capability.
 No production token counter is bundled or certified by this storage adapter.
+
+## Context pack storage contracts
+
+Context packs require workflow storage contract 2 or conversation storage
+contract 3. A fresh installation can explicitly use
+`store.initialize(context_packs=True)`. On an existing installation this call
+refuses to upgrade: drain **all writers to the affected shared schema**, then
+run the owner-only migration:
+
+```sh
+prosaic-harness-postgres migrate-context-packs --store workflows --dsn-env HARNESS_MIGRATION_DSN
+prosaic-harness-postgres migrate-context-packs --store conversations --dsn-env HARNESS_MIGRATION_DSN
+```
+
+`store.migrate_context_pack_storage()` is the equivalent API for either store.
+ALWAYS use migration-owner credentials and drain writers across namespaces.
+NEVER migrate from a worker, readiness check, or model invocation. An active
+lease in any namespace refuses migration. The schema-wide advisory lock and
+transaction preserve existing record bytes, revisions and grants. Repeating a
+completed migration is safe; older binaries reject the new schema version.
+New workers continue reading legacy records. Runtime credentials cannot migrate.
+
+The `context_packs_v1` capability appears only after explicit opt-in. Pack-aware
+workflow documents use canonical UTF-8 JSON; existing workflow document bytes
+and the conversation codec remain unchanged. Private snapshots and validation
+facts remain inside the bounded checkpoint/receipt, subject to host scope and
+retained-read authorization. No new database, blob table or automatic retention
+policy is introduced.

{b3_prosaic_harness_postgres-0.4.0 → b3_prosaic_harness_postgres-0.4.2}/README.md

@@ -1,27 +1,57 @@
 # PostgreSQL persistence for Prosaic Harness
 
+PostgreSQL adapter **0.4.2** requires Harness **0.9.13** or later
+in the compatible family. Explicit owner migration enables
+workflow storage contract2 or conversation contract3; readiness performs no DDL.
+See [context-pack migration and rollback](../../docs/context-packs.md#current-authorization-and-durable-storage).
+
+See [0.4.2 release and migration notes](../../docs/release-postgres-0.4.2.md)
+and [compatible SDK versions](https://github.com/B3Cognition/prosaic-harness/blob/main/docs/releases.md).
+
 Run on worker A, inspect/resume on worker B, without a shared writable run
 directory. Core remains database-free; install this separate adapter only when
 you need shared durable state. The API is synchronous; a private I/O thread
 bounds network waits. Model execution holds no database connection/transaction.
-The conversation candidate is `b3-prosaic-harness-postgres` **0.3.0**, selecting
-`b3-prosaic-harness>=0.8,<0.9`. The adapter is maintained in this repository but
-installed and versioned separately, keeping PostgreSQL drivers optional for
-Harness users. Imports and CLI names remain unchanged. Final qualification and
-publication of this conversation release train are pending. The historical
-[Harness v0.6.1 release](https://github.com/B3Cognition/prosaic-harness/releases/tag/v0.6.1)
-retains its original 0.6.1/0.1.1 package names and receipts.
+The adapter is independently versioned: `b3-prosaic-harness-postgres` **0.4.2**
+requires `b3-prosaic-harness>=0.9.13,<0.10`. PostgreSQL drivers remain optional for
+core Harness users. Imports and CLI names are unchanged.
+
+## Durability profiles
+
+The default `durability_profile="postgresql"` requires `full_page_writes=on`.
+An operator who has independently verified an Amazon Aurora PostgreSQL cluster
+may explicitly select `durability_profile="aurora-postgresql"` on both
+`PostgresRunStore` and `PostgresSessionStore` (including `from_env`). This accepts
+`full_page_writes=off` under Aurora's log-based storage contract. It does not
+weaken fsync, synchronous commit, writable-primary, logged-table, lease or
+unknown-commit checks. The guard runs for every operation and connection reuse.
+Invalid profiles fail before connecting. This profile is an operator assertion,
+not engine autodetection or proof that arbitrary storage is safe. NEVER select
+it for ordinary PostgreSQL just to suppress a readiness failure.
+
+For every CLI command, pass `--durability-profile aurora-postgresql` explicitly.
+Migration and runtime must select the same profile. Verify the actual engine and
+version with AWS RDS metadata/DBA evidence; AWS also documents `aurora_version()`.
+Capture a failed SQL probe's actual error and inspect its schema/search path;
+NEVER convert an unavailable probe into permission to bypass durability checks.
+No AWS credentials or model calls are needed by the adapter.
+
+AWS describes the storage contract in
+[its architecture guide](https://aws.amazon.com/blogs/database/is-amazon-rds-for-postgresql-or-amazon-aurora-postgresql-a-better-choice-for-me/).
+Native PostgreSQL tests qualify the policy and all existing recovery behavior;
+they do not emulate Aurora storage. An actual Aurora deployment needs synthetic
+persistence/restart/failover qualification before enabling production work.
 
 ## 1. Install and supply an existing database
 
 Python 3.11+, PostgreSQL 16 or 18 on a writable primary, and libpq 17+ are
 required. `psycopg[binary]` supplies libpq; older libpq is rejected.
-From the exact candidate Harness checkout, use a new environment and a curated
-wheelhouse containing only the manifest-selected b3 candidate wheels:
+Use a fresh environment and the published compatible SDKs:
 
 ```sh
 python3 -m venv .venv-postgres
-.venv-postgres/bin/python -m pip install --find-links /absolute/path/to/curated-wheelhouse . ./adapters/postgres
+.venv-postgres/bin/python -m pip install 'b3-prosaic-harness==0.9.11' \
+  'b3-prosaic-runtime==0.9.19' 'b3-prosaic-harness-postgres==0.4.2'
 export PATH="$PWD/.venv-postgres/bin:$PATH"
 prosaic --version
 prosaic-harness-postgres --help
@@ -29,8 +59,13 @@ prosaic-harness-postgres --help
 
 ALWAYS migrate using a fresh environment or image; NEVER install legacy and b3
 distributions together because they own the same import paths. See
-[package migration](../../docs/package-migration.md). The Runtime 0.9 candidate
-must be available before this installation can resolve.
+[package migration](../../docs/package-migration.md). For reproducible installs,
+verify the complete selected manifest's wheel hashes before installation.
+
+Agent reasoning effort is passed through Harness to Runtime; this store does
+not turn thinking on or prove provider compliance. Frozen prose/configuration
+and workflow identity still govern resume. See [reasoning effort](../../docs/reasoning-effort.md)
+and the Integration Lab's separate blueprint and control-check lane.
 
 Harness does **not** provision PostgreSQL, create databases/users, start a
 service, or fall back to files. Your operator supplies two DSNs through a secret
@@ -139,6 +174,10 @@ remain supported; the adapter adds no new workflow interpreter.
   budget 10s, pool/connect 5s, row lock 1s, statement 5s. Deadlines cover pool,
   network and COMMIT waits. Stalled connections are quarantined; unresolved
   operations retain capacity and prevent unsafe close.
+- Ordinary operations use the configured short lock timeout. Dedicated renewal
+  operations can wait for a same-owner write within the configured statement
+  and total operation deadlines. Failed renewal remains sticky; ownership and
+  generation checks still fence every write.
 - Default lazy pool bounds per store/process: 8 ordinary + 4 renewal connections,
   maximum 4 active leases. Renewal has reserved capacity. Multiply capacity
   across replicas/namespaces; do not create a pool per HTTP request. Applications
@@ -193,7 +232,7 @@ python adapters/postgres/tests/support/local_cluster.py stop --manifest "$FIXTUR
 Repeat with version 18. Stop validates exact IDs/names/ownership labels before
 removing only owned containers/volumes/network. Generated fixture networks and
 loopback ports use synthetic trust authentication, never production defaults.
-# Lease registration candidate
+# Lease registration
 
 The adapter transfers acquisition capacity into registered
 session capacity atomically under the existing store mutex. A registering lease
@@ -203,7 +242,7 @@ an owned PostgreSQL 16/18 race regression cover the transition.
 
 ## Optional conversation sessions
 
-The conversation candidate adds `PostgresSessionStore` to this same optional
+Conversation storage provides `PostgresSessionStore` to this same optional
 distribution. It implements the public Harness `SessionStore` contract and uses
 the independent, logged `prosaic_harness_conversations` schema, storage version 1.
 Existing `PostgresRunStore` tables, grants and CLI `init`/`doctor` behavior remain
@@ -295,7 +334,7 @@ The required adapter suite includes both the existing workflow backend and the
 conversation backend. Run the owned PostgreSQL 16 and 18 fixtures shown above
 with `--require-postgres`. Missing infrastructure or any skipped required case
 fails qualification. Installed Linux AMD64 and ARM64 acceptance is required
-before claiming the conversation candidate is ready for production.
+before treating a conversation deployment as ready for production.
 
 ## Optional context storage contract
 
@@ -315,3 +354,31 @@ cannot update schema metadata. Old workers reject the upgraded storage contract.
 Keep migration-owner credentials separate from runtime credentials. Enable host
 context policies only after Runtime, Harness and store advertise the capability.
 No production token counter is bundled or certified by this storage adapter.
+
+## Context pack storage contracts
+
+Context packs require workflow storage contract 2 or conversation storage
+contract 3. A fresh installation can explicitly use
+`store.initialize(context_packs=True)`. On an existing installation this call
+refuses to upgrade: drain **all writers to the affected shared schema**, then
+run the owner-only migration:
+
+```sh
+prosaic-harness-postgres migrate-context-packs --store workflows --dsn-env HARNESS_MIGRATION_DSN
+prosaic-harness-postgres migrate-context-packs --store conversations --dsn-env HARNESS_MIGRATION_DSN
+```
+
+`store.migrate_context_pack_storage()` is the equivalent API for either store.
+ALWAYS use migration-owner credentials and drain writers across namespaces.
+NEVER migrate from a worker, readiness check, or model invocation. An active
+lease in any namespace refuses migration. The schema-wide advisory lock and
+transaction preserve existing record bytes, revisions and grants. Repeating a
+completed migration is safe; older binaries reject the new schema version.
+New workers continue reading legacy records. Runtime credentials cannot migrate.
+
+The `context_packs_v1` capability appears only after explicit opt-in. Pack-aware
+workflow documents use canonical UTF-8 JSON; existing workflow document bytes
+and the conversation codec remain unchanged. Private snapshots and validation
+facts remain inside the bounded checkpoint/receipt, subject to host scope and
+retained-read authorization. No new database, blob table or automatic retention
+policy is introduced.

{b3_prosaic_harness_postgres-0.4.0 → b3_prosaic_harness_postgres-0.4.2}/pyproject.toml

@@ -4,13 +4,13 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "b3-prosaic-harness-postgres"
-version = "0.4.0"
+version = "0.4.2"
 description = "Explicit PostgreSQL run and conversation storage for Prosaic Harness"
 requires-python = ">=3.11"
 readme = "README.md"
 license = "Apache-2.0"
 license-files = ["LICENSE", "NOTICE"]
-dependencies = ["b3-prosaic-harness>=0.9,<0.10", "psycopg[binary]>=3.2.3,<4", "psycopg-pool>=3.2,<4"]
+dependencies = ["b3-prosaic-harness>=0.9.13,<0.10", "psycopg[binary]>=3.2.3,<4", "psycopg-pool>=3.2,<4"]
 
 [project.optional-dependencies]
 test = ["pytest>=8", "build>=1", "setuptools>=77", "wheel", "packaging"]

{b3_prosaic_harness_postgres-0.4.0 → b3_prosaic_harness_postgres-0.4.2/src/b3_prosaic_harness_postgres.egg-info}/PKG-INFO

@@ -1,13 +1,13 @@
 Metadata-Version: 2.4
 Name: b3-prosaic-harness-postgres
-Version: 0.4.0
+Version: 0.4.2
 Summary: Explicit PostgreSQL run and conversation storage for Prosaic Harness
 License-Expression: Apache-2.0
 Requires-Python: >=3.11
 Description-Content-Type: text/markdown
 License-File: LICENSE
 License-File: NOTICE
-Requires-Dist: b3-prosaic-harness<0.10,>=0.9
+Requires-Dist: b3-prosaic-harness<0.10,>=0.9.13
 Requires-Dist: psycopg[binary]<4,>=3.2.3
 Requires-Dist: psycopg-pool<4,>=3.2
 Provides-Extra: test
@@ -20,28 +20,58 @@ Dynamic: license-file
 
 # PostgreSQL persistence for Prosaic Harness
 
+PostgreSQL adapter **0.4.2** requires Harness **0.9.13** or later
+in the compatible family. Explicit owner migration enables
+workflow storage contract2 or conversation contract3; readiness performs no DDL.
+See [context-pack migration and rollback](../../docs/context-packs.md#current-authorization-and-durable-storage).
+
+See [0.4.2 release and migration notes](../../docs/release-postgres-0.4.2.md)
+and [compatible SDK versions](https://github.com/B3Cognition/prosaic-harness/blob/main/docs/releases.md).
+
 Run on worker A, inspect/resume on worker B, without a shared writable run
 directory. Core remains database-free; install this separate adapter only when
 you need shared durable state. The API is synchronous; a private I/O thread
 bounds network waits. Model execution holds no database connection/transaction.
-The conversation candidate is `b3-prosaic-harness-postgres` **0.3.0**, selecting
-`b3-prosaic-harness>=0.8,<0.9`. The adapter is maintained in this repository but
-installed and versioned separately, keeping PostgreSQL drivers optional for
-Harness users. Imports and CLI names remain unchanged. Final qualification and
-publication of this conversation release train are pending. The historical
-[Harness v0.6.1 release](https://github.com/B3Cognition/prosaic-harness/releases/tag/v0.6.1)
-retains its original 0.6.1/0.1.1 package names and receipts.
+The adapter is independently versioned: `b3-prosaic-harness-postgres` **0.4.2**
+requires `b3-prosaic-harness>=0.9.13,<0.10`. PostgreSQL drivers remain optional for
+core Harness users. Imports and CLI names are unchanged.
+
+## Durability profiles
+
+The default `durability_profile="postgresql"` requires `full_page_writes=on`.
+An operator who has independently verified an Amazon Aurora PostgreSQL cluster
+may explicitly select `durability_profile="aurora-postgresql"` on both
+`PostgresRunStore` and `PostgresSessionStore` (including `from_env`). This accepts
+`full_page_writes=off` under Aurora's log-based storage contract. It does not
+weaken fsync, synchronous commit, writable-primary, logged-table, lease or
+unknown-commit checks. The guard runs for every operation and connection reuse.
+Invalid profiles fail before connecting. This profile is an operator assertion,
+not engine autodetection or proof that arbitrary storage is safe. NEVER select
+it for ordinary PostgreSQL just to suppress a readiness failure.
+
+For every CLI command, pass `--durability-profile aurora-postgresql` explicitly.
+Migration and runtime must select the same profile. Verify the actual engine and
+version with AWS RDS metadata/DBA evidence; AWS also documents `aurora_version()`.
+Capture a failed SQL probe's actual error and inspect its schema/search path;
+NEVER convert an unavailable probe into permission to bypass durability checks.
+No AWS credentials or model calls are needed by the adapter.
+
+AWS describes the storage contract in
+[its architecture guide](https://aws.amazon.com/blogs/database/is-amazon-rds-for-postgresql-or-amazon-aurora-postgresql-a-better-choice-for-me/).
+Native PostgreSQL tests qualify the policy and all existing recovery behavior;
+they do not emulate Aurora storage. An actual Aurora deployment needs synthetic
+persistence/restart/failover qualification before enabling production work.
 
 ## 1. Install and supply an existing database
 
 Python 3.11+, PostgreSQL 16 or 18 on a writable primary, and libpq 17+ are
 required. `psycopg[binary]` supplies libpq; older libpq is rejected.
-From the exact candidate Harness checkout, use a new environment and a curated
-wheelhouse containing only the manifest-selected b3 candidate wheels:
+Use a fresh environment and the published compatible SDKs:
 
 ```sh
 python3 -m venv .venv-postgres
-.venv-postgres/bin/python -m pip install --find-links /absolute/path/to/curated-wheelhouse . ./adapters/postgres
+.venv-postgres/bin/python -m pip install 'b3-prosaic-harness==0.9.11' \
+  'b3-prosaic-runtime==0.9.19' 'b3-prosaic-harness-postgres==0.4.2'
 export PATH="$PWD/.venv-postgres/bin:$PATH"
 prosaic --version
 prosaic-harness-postgres --help
@@ -49,8 +79,13 @@ prosaic-harness-postgres --help
 
 ALWAYS migrate using a fresh environment or image; NEVER install legacy and b3
 distributions together because they own the same import paths. See
-[package migration](../../docs/package-migration.md). The Runtime 0.9 candidate
-must be available before this installation can resolve.
+[package migration](../../docs/package-migration.md). For reproducible installs,
+verify the complete selected manifest's wheel hashes before installation.
+
+Agent reasoning effort is passed through Harness to Runtime; this store does
+not turn thinking on or prove provider compliance. Frozen prose/configuration
+and workflow identity still govern resume. See [reasoning effort](../../docs/reasoning-effort.md)
+and the Integration Lab's separate blueprint and control-check lane.
 
 Harness does **not** provision PostgreSQL, create databases/users, start a
 service, or fall back to files. Your operator supplies two DSNs through a secret
@@ -159,6 +194,10 @@ remain supported; the adapter adds no new workflow interpreter.
   budget 10s, pool/connect 5s, row lock 1s, statement 5s. Deadlines cover pool,
   network and COMMIT waits. Stalled connections are quarantined; unresolved
   operations retain capacity and prevent unsafe close.
+- Ordinary operations use the configured short lock timeout. Dedicated renewal
+  operations can wait for a same-owner write within the configured statement
+  and total operation deadlines. Failed renewal remains sticky; ownership and
+  generation checks still fence every write.
 - Default lazy pool bounds per store/process: 8 ordinary + 4 renewal connections,
   maximum 4 active leases. Renewal has reserved capacity. Multiply capacity
   across replicas/namespaces; do not create a pool per HTTP request. Applications
@@ -213,7 +252,7 @@ python adapters/postgres/tests/support/local_cluster.py stop --manifest "$FIXTUR
 Repeat with version 18. Stop validates exact IDs/names/ownership labels before
 removing only owned containers/volumes/network. Generated fixture networks and
 loopback ports use synthetic trust authentication, never production defaults.
-# Lease registration candidate
+# Lease registration
 
 The adapter transfers acquisition capacity into registered
 session capacity atomically under the existing store mutex. A registering lease
@@ -223,7 +262,7 @@ an owned PostgreSQL 16/18 race regression cover the transition.
 
 ## Optional conversation sessions
 
-The conversation candidate adds `PostgresSessionStore` to this same optional
+Conversation storage provides `PostgresSessionStore` to this same optional
 distribution. It implements the public Harness `SessionStore` contract and uses
 the independent, logged `prosaic_harness_conversations` schema, storage version 1.
 Existing `PostgresRunStore` tables, grants and CLI `init`/`doctor` behavior remain
@@ -315,7 +354,7 @@ The required adapter suite includes both the existing workflow backend and the
 conversation backend. Run the owned PostgreSQL 16 and 18 fixtures shown above
 with `--require-postgres`. Missing infrastructure or any skipped required case
 fails qualification. Installed Linux AMD64 and ARM64 acceptance is required
-before claiming the conversation candidate is ready for production.
+before treating a conversation deployment as ready for production.
 
 ## Optional context storage contract
 
@@ -335,3 +374,31 @@ cannot update schema metadata. Old workers reject the upgraded storage contract.
 Keep migration-owner credentials separate from runtime credentials. Enable host
 context policies only after Runtime, Harness and store advertise the capability.
 No production token counter is bundled or certified by this storage adapter.
+
+## Context pack storage contracts
+
+Context packs require workflow storage contract 2 or conversation storage
+contract 3. A fresh installation can explicitly use
+`store.initialize(context_packs=True)`. On an existing installation this call
+refuses to upgrade: drain **all writers to the affected shared schema**, then
+run the owner-only migration:
+
+```sh
+prosaic-harness-postgres migrate-context-packs --store workflows --dsn-env HARNESS_MIGRATION_DSN
+prosaic-harness-postgres migrate-context-packs --store conversations --dsn-env HARNESS_MIGRATION_DSN
+```
+
+`store.migrate_context_pack_storage()` is the equivalent API for either store.
+ALWAYS use migration-owner credentials and drain writers across namespaces.
+NEVER migrate from a worker, readiness check, or model invocation. An active
+lease in any namespace refuses migration. The schema-wide advisory lock and
+transaction preserve existing record bytes, revisions and grants. Repeating a
+completed migration is safe; older binaries reject the new schema version.
+New workers continue reading legacy records. Runtime credentials cannot migrate.
+
+The `context_packs_v1` capability appears only after explicit opt-in. Pack-aware
+workflow documents use canonical UTF-8 JSON; existing workflow document bytes
+and the conversation codec remain unchanged. Private snapshots and validation
+facts remain inside the bounded checkpoint/receipt, subject to host scope and
+retained-read authorization. No new database, blob table or automatic retention
+policy is introduced.

{b3_prosaic_harness_postgres-0.4.0 → b3_prosaic_harness_postgres-0.4.2}/src/b3_prosaic_harness_postgres.egg-info/SOURCES.txt

@@ -12,6 +12,7 @@ src/b3_prosaic_harness_postgres.egg-info/top_level.txt
 src/prosaic_harness_postgres/__init__.py
 src/prosaic_harness_postgres/cli.py
 src/prosaic_harness_postgres/leases.py
+src/prosaic_harness_postgres/pack_schema.py
 src/prosaic_harness_postgres/schema.py
 src/prosaic_harness_postgres/session_leases.py
 src/prosaic_harness_postgres/session_schema.py
@@ -20,7 +21,11 @@ src/prosaic_harness_postgres/store.py
 src/prosaic_harness_postgres/transport.py
 tests/conftest.py
 tests/test_cli.py
+tests/test_context_pack_migrations.py
+tests/test_context_pack_platform.py
+tests/test_context_pack_recovery.py
 tests/test_durability.py
+tests/test_durability_profiles.py
 tests/test_engine.py
 tests/test_examples.py
 tests/test_leases.py
@@ -29,6 +34,7 @@ tests/test_native_factory.py
 tests/test_packaging.py
 tests/test_recovery.py
 tests/test_registration.py
+tests/test_renewal_contention.py
 tests/test_routing.py
 tests/test_schema.py
 tests/test_session_context.py

{b3_prosaic_harness_postgres-0.4.0 → b3_prosaic_harness_postgres-0.4.2}/src/b3_prosaic_harness_postgres.egg-info/requires.txt

@@ -1,4 +1,4 @@
-b3-prosaic-harness<0.10,>=0.9
+b3-prosaic-harness<0.10,>=0.9.13
 psycopg[binary]<4,>=3.2.3
 psycopg-pool<4,>=3.2
 

{b3_prosaic_harness_postgres-0.4.0 → b3_prosaic_harness_postgres-0.4.2}/src/prosaic_harness_postgres/__init__.py

@@ -1,5 +1,5 @@
 """Separate PostgreSQL adapter for Prosaic Harness."""
-__version__ = '0.4.0'
+__version__ = '0.4.2'
 
 from .store import PostgresRunStore
 from .session_store import PostgresSessionStore

{b3_prosaic_harness_postgres-0.4.0 → b3_prosaic_harness_postgres-0.4.2}/src/prosaic_harness_postgres/cli.py

@@ -44,21 +44,31 @@ def check_write(store):
 def main(argv=None):
     parser = argparse.ArgumentParser(description='Initialize/check an existing Harness database')
     commands = parser.add_subparsers(dest='command', required=True)
-    for name in ('init', 'doctor', 'migrate-conversations'):
+    for name in ('init', 'doctor', 'migrate-conversations','migrate-context-packs'):
         command = commands.add_parser(name)
         command.add_argument('--dsn-env', required=True, help='name of the DSN environment variable, never its value')
+        command.add_argument('--durability-profile', choices=['postgresql', 'aurora-postgresql'],
+                             default='postgresql', help='explicit operator-verified database storage contract')
+        if name=='migrate-context-packs': command.add_argument('--store',choices=['workflows','conversations'],required=True)
         if name == 'doctor':
             command.add_argument('--check-write', action='store_true', help='explicit disposable write test; DELETE credentials required')
     args = parser.parse_args(argv)
     try:
+        if args.command=='migrate-context-packs':
+            from .session_store import PostgresSessionStore
+            cls=PostgresRunStore if args.store=='workflows' else PostgresSessionStore
+            with cls.from_env(args.dsn_env,namespace='pack-migration',durability_profile=args.durability_profile) as store:
+                store.migrate_context_pack_storage()
+            print(json.dumps({'migrated':True,'store':args.store,'storage_contract':2 if args.store=='workflows' else 3}))
+            return 0
         if args.command == 'migrate-conversations':
             from .session_store import PostgresSessionStore
-            with PostgresSessionStore.from_env(args.dsn_env, namespace='conversation-migration') as store:
+            with PostgresSessionStore.from_env(args.dsn_env, namespace='conversation-migration', durability_profile=args.durability_profile) as store:
                 store.migrate_context_storage()
             print(json.dumps({'migrated': True, 'conversation_storage_contract': 2}))
             return 0
         namespace = 'prosaic-diagnostic-' + uuid.uuid4().hex
-        with PostgresRunStore.from_env(args.dsn_env, namespace=namespace) as store:
+        with PostgresRunStore.from_env(args.dsn_env, namespace=namespace, durability_profile=args.durability_profile) as store:
             if args.command == 'init':
                 store.initialize()
                 result = {'initialized': True, 'schema_version': 1}

b3_prosaic_harness_postgres-0.4.2/src/prosaic_harness_postgres/pack_schema.py

@@ -0,0 +1,31 @@
+"""Owner-only, schema-wide opt-in; never rewrite run or receipt documents."""
+from prosaic_harness import StoreIncompatible,StoreUninitialized,StoreBusy
+
+
+def migrate(transport,*,schema,target,versions,lock,ready):
+    # These identifiers are internal constants, never user/model data.
+    if (schema,target) not in {('prosaic_harness',2),('prosaic_harness_conversations',3)}:
+        raise StoreIncompatible()
+    async def operation(conn):
+        await conn.execute("SELECT pg_catalog.set_config('lock_timeout','25000ms',true), "
+            "pg_catalog.set_config('statement_timeout','28000ms',true)")
+        await conn.execute('SELECT pg_catalog.pg_advisory_xact_lock(%s)',(lock,))
+        owner=await (await conn.execute("SELECT pg_catalog.pg_has_role(nspowner,'USAGE') "
+            'FROM pg_catalog.pg_namespace WHERE nspname=%s',(schema,))).fetchone()
+        if owner is None: raise StoreUninitialized('initialize storage explicitly first')
+        if owner[0] is not True: raise StoreIncompatible('migration role must own the adapter schema')
+        current=await (await conn.execute('SELECT schema_version,storage_contract_version FROM '+schema+'.schema_version')).fetchall()
+        if len(current)!=1 or current[0] not in versions: raise StoreIncompatible('migration requires intact known storage')
+        await ready(conn,expected_versions=current[0])
+        if current[0]==(target,target): return
+        # Includes every namespace. This transaction is brief and never spans
+        # inference, a counter, a validator or any host callback.
+        await conn.execute('LOCK TABLE '+schema+'.leases IN EXCLUSIVE MODE')
+        active=await (await conn.execute('SELECT EXISTS(SELECT 1 FROM '+schema+'.leases '
+            'WHERE owner IS NOT NULL AND expires_at>pg_catalog.clock_timestamp())')).fetchone()
+        if active[0]: raise StoreBusy('drain all writers to the shared schema before migration')
+        changed=await conn.execute('UPDATE '+schema+'.schema_version '
+            'SET schema_version=%s,storage_contract_version=%s WHERE singleton IS TRUE',(target,target))
+        if changed.rowcount!=1: raise StoreIncompatible()
+        await ready(conn,expected_versions=(target,target))
+    return transport.call(operation,timeout_s=30)