the-custodian/docs/changes/netkingdom-target-2026-10-16/group-postgres-r1/native-fixture

Prepared disposable PostgreSQL compatibility fixture

Status: prepared and unit checked; not executed or approved. Default python3 driver.py --plan reads only the manifest, without loading containment, generating material or calling Docker. Execution requires independent review of the exact manifest/source closure and explicit execution flag/digest. The flag and fixture files confer no authority.

The fixture reuses the existing isolated-keycape.py command/environment guard, containment inspector and exact name/label cleanup. A network-none PostgreSQL anchor and a pinned cached User Engine Python helper share only loopback. Both are nonroot/read-only/capability-free, with private bounded tmpfs, no host ports, mounts or Docker socket, and no pulls/builds/packages. Generated admin/runtime passwords enter through stdin only. Image-specific nonroot UID999/Python/psycopg compatibility is an explicit precondition checked by execution; no cache or runtime claim is made during preparation. Any incompatible image/anonymous volume/error fails closed and still invokes exact cleanup.

Six sequential Python phases use the actual candidate SQL backend and its normal provisioner path with the existing synthetic LDAP Directory. Bootstrap runs the real migration on generated state, checks runtime DDL denial and exact created-only inventories. A separate process reopens and replays/revokes while preserving the complete synthetic prestate. Concurrent reservations must yield one original receipt; stale row CAS cannot advance its head. Two actual database clones then pass the same old checkpoint check concurrently and commit different receipts at the same next counter. Only one external digest CAS may win; a fresh backend on the losing clone must refuse even at that same counter. Lost checkpoint acknowledgment, lost synthetic directory response and a lost reply after actual SQL commit must retain pending/uncertain state and refuse continuation. An actual pg_dump taken after bootstrap is then pg_restored after later journal changes; the external test checkpoint survives. Runtime SQL SELECT must work and show an older restored head before the candidate's restore-quarantine refusal oracle can pass. This prevents an unrelated connection/ACL failure from masquerading as restore protection.

All fresh names/labels are registered before create. finally uses the existing cleanup helper for both resources, requires successful exact absence inventories and retains any Docker uncertainty as failed. PID1 lifetimes and RPC/execution limits are bounded in the manifest. This is not a parent-death/reaper proof. Only safe booleans, public image/source/version pins and cleanup duties leave in a private /tmp/nk48-postgres-native-review-*/result.json; synthetic backup bytes are bounded in host memory and never written as an archive file.

The test checkpoint implementation belongs only to this fixture. Its independent file survives PostgreSQL restore and uses file locking/fsync; it is not offered as native custody, case authority, a journal-recovery API or an evidence broker. The fixture explicitly disposes one definitely pre-LDAP synthetic reservation to move between fault cases; it does not clear an unknown native mutation. All source/fixture passes remain distinct from live CNPG/lease/TLS/backup continuity, protected owner callbacks, actual authoritative tenant scope, native LDAP fencing and production acceptance.

R2 cached helper selection

The reviewed R1 preflight failed before execute, session allocation or private import because its pinned helper image 1e6547 was absent. No pull or override was used. Frozen manifest/driver/probe/source and the coordinator's structured failure are retained under revisions/r1. There is no raw stderr file; the original traceback was returned in tool output only, so no byte-exact stderr artifact is invented.

The proposed R2 helper is the coordinator-observed cached f239 image, bound by existing published receipts to User Engine source 1bb7cacc. That source uses system pip on official Python 3.12, not a virtualenv. R2 therefore binds every helper launch/exec to /usr/local/bin/python3; it has no PATH or alternate-venv fallback. A closed in-container probe must verify the exact executable and import psycopg 3 before candidate source import, reporting the bundled version. Missing or mismatched interpreter/dependency refuses and preserves exact cleanup duties. No container count, limit, privilege, network or cleanup expansion is proposed. Historical producer or rollout acceptance is not a new image/dependency grant. See helper-selection-r2.json, manifest-delta-r2.json and preparation-r2.json.

R3 bounded failure diagnostics

R2 executed and failed after containment and interpreter verification (bundled psycopg 3.3.6); all phase checks were empty. Its unchanged receipt and manifest are preserved in revisions/r2. The old driver discarded a failed helper result, so the exact failing subphase is unknown. Bootstrap is not asserted as the cause.

R3 adds fixed public driver/RPC markers and helper NDJSON markers, retained before an oracle raises. PostgreSQL initdb now completes synchronously with only a fixed boolean result before the detached server launch. Bootstrap separately identifies connection readiness, migration, epoch insertion, role/grants, checkpoint and ensure/readback. Failures expose only an allowlisted exception class and optional five-character SQLSTATE, including a wrapped cause; never exception messages, SQL/DSN/password values, command arguments or database logs. Public frames are bounded to 32768 bytes and 96 lines; RPC trace is bounded to 192 fixed rows. The safe result is checkpointed before/after each RPC and on helper failure. This remains a sequential fixture, with unchanged images, authority, backend source, oracles, container/network limits and exact cleanup requirements. No retry or runtime execution is authorized by this diagnostic revision.

R4 demonstrated receipt-reference fix

R3 reached bootstrap ensure and failed before readback, with fixed RuntimeError class and no SQLSTATE. Its safe receipt and full source/fixture are retained. Local tests demonstrated the candidate's save method detached the provisioner's nested group-state reference while acknowledging a journal version. R4 changes only that method to update the acknowledged PostgreSQL version in place after commit/checkpoint success. The original failing regression and complete real provisioner ensure path pass locally with the fix. No diagnostic/fixture driver, phase oracle, SQL privilege, resource, image, network or cleanup change is made. The runtime failure is not claimed to be fully resolved until reviewed execution.

R5 faithful synthetic directory snapshots

R4 passed all five real PostgreSQL bootstrap checks, then failed during restart without a fine-grained marker. Its safe receipt and fixture/source are frozen. Local execution of the existing Directory/provisioner proved two fixture snapshot errors: returning the mutable group mapping let ensure contaminate the prestate before JSON serialization; and the test double retains empty membership backing sets for successfully deleted groups even though _directory no longer exposes their IDs. R5 copies the group map and snapshots full memberships for every current group ID. It explicitly refuses any nonempty orphan, rather than ignoring unknown membership. Two local source-backed tests reproduce the old failure, prove exact detached prestate after real ensure/revoke, and reject changed shared memberships or nonempty orphans. The semantic complete visible-prestate equality and all phase oracle names remain intact. Restart now has fixed load/reopen, replay/revoke/readback/prestate/foreign-context markers. Backend source5549, image pins, resources and exact cleanup remain unchanged; actual compatibility awaits independent exact review and execution.