Collection and snapshot contracts

Bounded pilot. Collections group native assets and account-owned source selections within a project. They store only IDs; no copy, conversion, authority transfer or sharing permission results. No source metadata from another account is exposed. Members resolve the existing source follow/pin policy or current native asset. A collection is not an exact snapshot, a scene or a multi-source transaction.

Browser POST /api/collections/{list,options,save,delete} requires session, Origin and CSRF plus current project access. It requires no administrator role. Collections are keyed by project/account, never implicitly shared. Automation and desktop collection routes are absent. project_id is required for every call. Save takes id (null for create), name, description, members (native:/source:) and generation (0 at create). IDs must occur in the caller’s current catalogue. Existing save/delete must match generation or return 409. Unknown/foreign collection and denied project return 404. Invalid input is 400. Delete requires ID and generation and removes grouping only. List returns currently visible IDs and unavailable count; saving the visible list explicitly drops unavailable references. Limits: 100 groups per account/project, 200 distinct IDs/group, 160-character name, 2000 description. Retry a failed edit after reloading. A lost create response requires checking the list before retrying (creation is not idempotent). Existing-source access checks still occur when reading payloads. The gateway journal backup includes collections.

Optional review

Release capture accepts review_required (strict boolean, defaults true for older clients). False starts in snapshot; true preserves candidate. Only project administrators with their own source access can capture/options/request-review. Retention AND redistribution policy remain mandatory, even for personal snapshots. Current project membership, frozen audience and current policy govern every read.

snapshot -- request-review --> candidate -- approve --> approved
    |                             |                       |
    +-----------------------------+-------------------- withdraw --> withdrawn

download-snapshot (read scope) only accepts snapshot state. Anyone in its permitted audience can immediately download. request-review (write scope and administration) takes ID and manifest_digest; it records actor/time, preserves the immutable manifest and pauses downloads until approval. Same request retry while candidate is idempotent; retry after approval/withdrawal is 409. Existing downloads cannot be recalled. download still requires approved. Both operations reuse existing release automation read/write scopes, project matching and recipient checks; desktop release routes remain absent. Neither path publishes upstream or starts subscriber delivery.

Snapshot ZIP uses filename snapshot-.zip. Its unchanged scientific manifest uses ophiolite.reviewed-release/1 so subsequent approval can bind the same digest. Receipt schema is ophiolite.snapshot-receipt/1, approval null, review_state unreviewed, with an explicit UNREVIEWED notice. Approved ZIP uses the existing release receipt schema. Do not infer approval from manifest schema or filenames; inspect the receipt. Hashes prove consistency, not author authenticity. Units, CRS, nulls and original bytes are unchanged. Same Stage 1 capture/preview/storage limits and supported file/SQL profiles. Collections may include OSDU/native data that this retained package reader cannot capture. The client lists omissions and requires acknowledgement of the subset.