Produce an acceptance report connecting the proposed snapshot, the remote version inspected, the attempted write and the final stored inventory. A passing version precondition alone does not establish that the proposed source is current or approved.

## Key Points

- [Cloud Storage request preconditions](https://docs.cloud.google.com/storage/docs/request-preconditions)
- [Cloud Storage object generations](https://docs.cloud.google.com/storage/docs/metadata)
- [Cloud Storage generation-specific reads](https://docs.cloud.google.com/storage/docs/json_api/v1/objects/get)

Object Snapshot Mirror Regression Test

Produce an acceptance report connecting the proposed snapshot, the remote version inspected, the attempted write and the final stored inventory. A passing version precondition alone does not establish that the proposed source is current or approved.

Establish the application's contract

Identify the exact destination, authoritative source revision, snapshot schema, permitted edits and outcome reporting. Derive preserved invariants from the application: for a reviewed queue these might include existing IDs, their destinations and source holds. They are not universal object-storage rules. Include fields the downstream consumer needs; retaining an ID is insufficient if the consumer silently drops its malformed row.

Determine how source freshness is established. A trusted revision or source-lineage check differs from an application timestamp. A newly stamped old snapshot can still be stale. Record the actual guarantee rather than claiming timestamp monotonicity proves ancestry. Do not assume metadata fields, ordering rules, checksums or headers the provider or application does not supply.

Use a bounded local HTTP fixture or an explicitly authorized test destination with synthetic inventories. Inventory replacement and competing writes are active tests, not a production read-only audit. Keep other destinations and downstream publishing disabled. Setup or observer failure is unavailable evidence.

Separate source validity from atomic replacement

Exercise a permitted update first, then retrieve and compare the final inventory with the candidate. Record the candidate hash and semantic comparison policy; formatting differences need not mean different application state. Check the caller's success status and, for a CLI, its exit code. An identical repeat should match the application's documented no-op or rewrite contract.

Next give the mirror an older source while allowing it to read the current remote version. This is the stale-source-with-fresh-precondition case: a compare-and-swap can succeed while restoring obsolete data. Test forbidden deletions, retargeting or approval changes only where the application forbids them. Require unchanged remote state and the correct failed invariant, not just an error message. Also exercise a missing consumer-required field.

Control both race windows

Use deterministic barriers instead of relying on timing luck. Pause after remote metadata is read; replace the remote object before its body is fetched. Verify that the compared body belongs to the inspected version or that the operation explicitly fails. A name-only read can otherwise pair one version's metadata with another version's bytes.

Separately pause after comparison but before replacement, then commit a competing valid update. The mirror's write must remain conditional on the version it inspected. Observe the actual condition sent and the final competing inventory. A conflict must not trigger a blind retry that reads a new version and overwrites it with the old candidate.

For GCS JSON API, generation selects an object revision on a read; ifGenerationMatch conditions a write on the current revision. A mismatch returns 412. Generation values identify versions, but need not increase: preserve their exact representation and do not use their numerical order as source chronology. Other stores require their documented equivalent.

Test unavailable and uncertain outcomes

Separate confirmed absence from denied access, malformed metadata/body, truncated input and bounded read timeout. Only the provider's documented absence result permits the application's create path. With GCS, ifGenerationMatch=0 makes a data write create-only; race a competing create and confirm it survives. Never convert an unreadable object to an empty baseline.

Make the fixture commit a write and drop its response. Inspect final bytes and available operation evidence through bounded reads. A lost response does not prove failure; byte equality establishes matching state, not necessarily which writer produced it. Report confirmed state and attribution separately. Preserve the original payload and condition. Do not clear the condition, refresh it to authorize the stale payload, or automatically resend an uncertain write. Any permitted retry needs the provider's actual guarantee for that same request and an explicit stopping rule.

Exercise both a rejected write and a transport failure through the real CLI or caller. A helper returning a failure value must not become an exit-zero success message. Distinguish confirmed write, documented no-op, conflict, definite failure and unresolved outcome.

Demonstrate that the checks detect faults

Run the same procedure against a valid implementation and isolated negative controls: omit the conditional write, bypass the source/inventory check, or report success after a failed upload. Check actual request history, stored bytes and process results. Keep expected answers separate from a forward evaluator where practical; a named test or static phrase check is not evidence of task success.

Record source and fixture versions, candidate/final hashes, observed remote version, request order and conditions, response status, write/effect counts, exit status and the precise violated invariant. Separate attempts from applied writes. State unexercised races and unavailable observations. Fixture evidence does not prove production IAM, all provider behavior, universal rollback prevention, causal agent improvement or adoption.

References and rights

Primary documentation checked 2026-10-30:

• Cloud Storage request preconditions
• Cloud Storage object generations
• Cloud Storage generation-specific reads

Original SkillDB-authored task procedure under LicenseRef-SkillDB-Content. References verify behavior; no source prose or example code is copied. The public adapter's MIT license does not grant MIT rights to catalog skill bodies.