@finueva/drive 0.22.0 → 0.23.0

package/CHANGELOG.md

@@ -1,5 +1,15 @@
 # @finueva/drive
 
+## 0.23.0
+
+### Minor Changes
+
+- 33501b2: Add explicit provider-validated SHA256 single-upload negotiation for files up to 8 MiB, including conditional version saves. Preserve legacy upload headers unless opted in, validate the signed checksum and immutable-object requirements, and retain authenticated verified readiness before publication.
+
+### Patch Changes
+
+- b32bff2: Read retained version and upload-part evidence in one scoped D1 snapshot for file previews and downloads.
+
 ## 0.22.0
 
 ### Minor Changes

package/README.md

@@ -180,6 +180,8 @@ The six low-level upload methods map directly to the Native API. `createUpload`
 
 Publication independently verifies archive bytes against both whole-file and part SHA-256 declarations. `getUploadStatus` exposes bounded confirmed-part pages and read-only verification progress once verification is admitted. `completeUpload` and `uploadFile` return `DriveOperationResult<UploadCompletion, 200 | 202>`: inspect `data.state` for `ready` versus `verifying`. A `202` is not publication. Retain its `uploadId` and the original completion idempotency key, inspect status, then call `completeUpload` again with that key when appropriate. The SDK does not start an unbounded polling loop. To cancel after a pending result, call `abortUpload({ workspaceId, uploadId })`, which returns bodyless `204`.
 
+After service support, its migration and the actual archive provider have been qualified, `uploadFile` and `uploadFileVersion` can opt in with `singleIntegrity: "sha256"`. Nonempty files up to 8 MiB then use a signed full SHA256 instead of the transport MD5 header, plus stored `cache-control: no-store, no-transform`. Drive authenticates the exact immutable object's full-checksum HEAD receipt and seals it before the normal fresh-authority publication checks; it does not trust the caller's digest or PUT response as proof. The SDK rejects unsigned checksum/cache-control/length requirements, wrong checksums and a downgrade to the legacy tuple. Archive CORS must allow `x-amz-checksum-sha256` and `cache-control` alongside the existing media type, create-only and encryption headers. Omit the option for an older service; zero-byte and larger multipart uploads retain bounded byte verification.
+
 `uploadFile` is the browser-safe direct-byte path for a Web `Blob` or `File`. It accepts zero-byte input, hashes the empty input correctly, accepts the server-mediated zero-byte mode, skips part transfer, and completes normally. Nonempty input is incrementally hashed in slices no larger than 32 MiB and is never materialized as a complete `ArrayBuffer`, Blob copy, base64 string, or SDK request body. The fixed policy permits at most 10,000 parts and 312.5 GiB.
 
 Each nonempty slice is sent directly to the exact descriptor URL. The SDK computes MD5 with the maintained Noble public API on the same bounded slice as SHA-256. Requests include only descriptor-required headers and use `credentials: "omit"`, `cache: "no-store"`, `redirect: "error"`, and `referrerPolicy: "no-referrer"`. Archive CORS must allow `content-md5` and expose `ETag`; no provider SHA response header is required, and ETags are never interpreted as hashes. If a Content-MD5 response header is exposed, it must match the request. Drive credentials, cookies and file metadata never enter the archive request.