Managed record assets integration

Verification Boundary

Managed-asset lifecycle rows, record reference adoption, cleanup scheduling and cleanup consumption cross local storage-adapter and PostgreSQL seams.

What This Suite Proves

The tests distinguish prepared objects from attached and retired assets, verify read authorization decisions and establish reuse, cleanup eligibility, record adoption and abandoned-object handling. Cleanup failure tests retain rows or repair references according to the actual outcome. The managed-asset table tests refuse malformed lifecycle rows by named constraints.

What It Does Not Prove

In-memory storage cannot prove deployed S3 permissions, bucket retention or queue delivery. Record field validation belongs to the contact and organization groups. A settled local cleanup consumer does not demonstrate a deployed schedule firing or an alarm detecting exhausted work.

Level and Rationale

The prepare-before-commit pipeline can leave objects outside a record transaction. Only an integration boundary can establish the relationship between attached record values, managed rows and cleanup work after failure. A unit test of a state label cannot establish safe physical-object retirement.

Real Dependencies and Test Doubles

PostgreSQL and the SQL lifecycle store are real. The source-declared in-memory asset store preserves versions and pins; the import cases use a local HTTP server and resolver. Cleanup queue and storage failures are supplied at explicit seams, so the observed proof concerns compensation rather than AWS connectivity.

Must Not Be Doubled

Never replace the SQL lifecycle store, record-reference inspection or the cleanup decision under test. Preserve object version behavior in the storage double. A permissive fake copy that ignores version changes could let a stale object appear safely adopted.

Fixtures and Isolation

The group creates its own objects and managed rows, and makes only its own rows due for cleanup. This matters because the sweep claims due work across workspaces. Cleanup restores the pipeline dependencies and removes owned rows; running serially avoids process-wide storage injection conflicts.

Determinism and Retries

Object keys and managed identities use scoped fixtures. Eligibility windows and deliberate failure outcomes are supplied explicitly rather than waiting for an external service. No retries are added by the register: abandoned or unprocessed rows are asserted as the actual failure result.

How It Runs

Run the command in the frontmatter from the service repository after preparing the test database. It selects every file in this aggregate register under the repository Mocha bootstrap and runs serially. This is the aggregate selection of the integration gate; the complete repository integration command includes other modules and is wider than this register.

Coverage Gaps

Local cleanup coverage leaves deployment grants, schedule cadence and dead-letter behavior for the component and resource pass. This integration register supplies no lifecycle proof through a public record API by itself. An asset cleanup is not a contact delete lifecycle, even when deletion makes an asset due.