Technical specification: Store compatibility guardrails for OKF v0.2

Historical document from source revision 61e75e9. This plan records the work proposed at that revision; it is not current implementation guidance. Original source.

1. Verdict

The backend-neutral store is already specification-agnostic. No production API migration is needed. This task is a verification/no-op guardrail and is closed after integration.

2. Preserve unchanged

• Store, Snapshot, ChangeSet;
• ChangeSetFormatVersion;
• Preview, CommitReceipt, CommitReceiptFormatVersion;
• the diagnostic wire shape;
• store.Actor validation.

New frontmatter families belong to bundle/validator/mutation.

3. Receipt boundary

store.CommitReceipt is evidence of transaction durability. executor.receipt is an Attested Computation runtime artifact.

Do not:

• add executor receipts or verdicts to CommitReceipt;
• bump the format version because of OKF v0.2;
• turn store into an execution or attestation cache;
• restrict store.Actor to the actor convention for document metadata.

4. Guardrail tests

All tests follow AAA.

• New validator codes pass through Preview.Diagnostics without losing code/file/severity/message.
• v0.1 and v0.2 bundles use the same transaction protocol.
• Document actors and legacy store actors are accepted; the whitespace/control/UTF-8 policy remains unchanged.
• Executor-like JSON is not accepted as a canonical transaction receipt.
• Existing ChangeSet/Receipt canonical bytes remain unchanged.

5. Acceptance criteria

• Public interfaces and format versions remain unchanged.
• Integration go test ./store ./mutation ./store/fs passes.
• Documentation explicitly distinguishes the two receipts.

6. Out of scope

Execution, attestation storage/cache, and a generic raw asset operation unless a separate migration contract requires one.